HTML/Middle-click/Security question...

[Brandon Sandrowicz]

Madison Kelly wrote:
> Rick Delaney wrote:
>> On Mar 09 2007, Madison Kelly wrote:
>>> Hi all,
>>>
>>>   For security reasons, on a site I am writing I have made it so that 
>>> you cannot pass variables in the URL (ie: 
>>> http://domain.com/cgi-bin/script.cgi?foo=bar&baz=boo fails). I do 
>>> this by only allowing variables to be passed via a form by checking 
>>> that the script was called via a POST instead of a GET command before 
>>> CGI variables are read.
>>
>> Switching from GET to POST adds no extra security whatsoever.  Now you
>> can forget about "middle-click" and go back to solving your real
>> problem.
>>
>> HTH,
> 
> I have no doubt you are right (I myself have never claimed to be an 
> expert in security). Could I ask though for you to elaborate a bit on 
> why it doesn't help or what methods I could look at that might be better?
> 
> For a better overview; here is a rough overview of how I handle 
> security. Perhaps you can point out other weak points?
> 
> - To prevent users trying to pass variables manually I wanted to 
> restrict the program to only pick up variables that were POST'ed (which 
> brings me to this thread). I've seen so many attacks that worked by 
> passing screwed up strings after the script name (my logic for this). 
> Also, I check that the source of the POST was my server (to hopefully 
> prevent an attacker from making their own form on another server).
> 
> - Passwords are made up of the user's string stuck onto a 32 bytes salt 
> (made up of alternating mixed-case letters, numbers and non-alphanumeric 
> characters) and then converted into a SHA256 hash (many times). The salt 
> is saved in the server's database and is replaced when the password is 
> changed.
> 
> - Cookies store only two pieces of information; the user's ID (in the 
> server's database) and a SHA256 hash result of: 
> '<user_id>:<today_date>:<random_number>:<browser_UA>'. The random number 
> is created when a user logs in and is stored in the database. When a 
> user subsequently calls a script I take the user_id from the cookie, 
> today's date, the random number from the DB and the browser's UA and 
> generate a SHA256 hash. It matches the hash in the user's cookie, the 
> session in validated. If the time passes midnight the validation code 
> checks to see if the previous date generates the matching code and, if 
> so, creates a new random number and updates the cookie's hash with the 
> new hash for the new day.
> 
> - Once devel is done this will all be encrypted via SSL.
> 
>   I am quite curious to know how people go about protecting against 
> user's manually creating URLs with bogus/malicious code/variables.
> 
> Thanks!
> 
> Madison

You do realize that people can create fake POST data too.  HTTP is a 
protocol, so I just need to write a program that talks HTTP and I can 
send all the fake data to it that I want.  I don't need to 'create a 
form on another server.'  Anyone serious about breaking into your site 
would just use a program based on an HTTP library and send whatever fake 
data that they want to.

You protect against bad data by error-checking every piece of data that 
comes into your webapp from user-input.  You can't trust any piece of 
info that your users give you.  You can't even just redisplay the raw 
data that they give you (that's how XSS -- cross-site scripting attacks 
-- work).

People get their sites broken into by large GET strings because:
1) Error in Apache handling GET strings that are too long
2) Error in PHP/Perl/Python/mod_perl/mod_php/mod_cgi/etc in handling 
long GET strings
3) The webapp itself doesn't error check user-provided data and just 
happily assumes that it is good data, then gets burned. Or else assumes 
that it can't get burned, even if it's bad data (in the case of XSS 
attacks the developer probably wasn't worried since the data wasn't even 
going to touch the DB).

Most of the time it's #3.  Apache/Perl/PHP/etc are fairly mature 
software compared to Xtreme AJAX WebApp of the week.

Brandon
--

--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists