Re: checking web applications for exploits

[Matthew Finkel <matthew.finkel () gmail com>]

On 07/24/11 19:40, Littlefield, Tyler wrote:
> Hello all:
> I'm working on a web application that is the registration and 
> management frontend for a database-driven game. I've created the 
> registration script, and I am on to my login script, but I want to 
> know what sort of exploits and security problems exist for my current 
> setup. I don't have a huge base, but I'd like to be able to pin these 
> down and fix them as soon as possible. Is there a way to test these? 
> What sorts of things do I need to look out for in terms of sessions 
> and the like? I do not know much about security for web applications, 
> so I am worried that I may have left something open that can be used 
> to make a huge mess.
> Essentially my security looks like this. I created the user and the 
> database, and I did not give the user a whole ton of privileges; I add 
> those as-needed. Each input to the web form is validated based on 
> length and a couple other factors depending on the data being 
> inputted, and -anything- going to the database goes through this 
> function before it gets validated.
> function CleanupInput($input)
> {
>     return  mysql_escape_string(addslashes($input));
> }
> Any other thoughts?

SQL injection (sqli) attacks are definitely one of the most prevalent, 
recently, regarding database insecurity, so sanitizing the login values 
is definitely an important start. In addition to this, make sure all 
data between the client and server is communicated over TLS (if you 
don't already have this implemented, there are dozens of tutorials for 
apache, and I assume a similar number for all the various other web 
server apps (IIS, nginx, etc). The next point, as Madhur said, is to 
remove any possibility of brute force password guessing. If you don't 
have some sort of timeout/lockout mechanism in place, then any attacker 
can simply enumerate a list of common usernames and passwords (possibly 
hundreds or thousands of times). Even with a small user base, someone is 
bound to use something guessable. Also, on that note, implement password 
requirements (at least 8 characters, at least 2 capital letters, at 
least 2 numbers, at least two symbols,.... whatever you choose) because 
this will also severely hinder the success of any brute force attack.

Another quick mention on SQLi (and any input validation attack, for that 
matter) is that it's a relatively easy exploit to counter. You just have 
to consciously remember to validate/sanitize any input coming from a 
POST or GET request (exactly like you did with you did for the database 
input). In addition this includes any conditional/variable include 
statements you have. Basically, if the user can affect a value that is 
relied on internally, you really need to make sure that value will be 
what you think it is.

I probably should have also covered XSS (cross site scripting) and cross 
site forgery, but maybe someone else can. If not, I'll try to come back 
and send in a small piece covering that. If I don't get a chance, there 
are a bunch of resources on the web that cover it, so it may be a good 
idea to check them out, too.

In any case, hope that helps (and sorry it's a bit long)

------------------------------------------------------------------------
Securing Apache Web Server with thawte Digital Certificate
In this guide we examine the importance of Apache-SSL and who needs an SSL certificate.  We look at how SSL works, how 
it benefits your company and how your customers can tell if a site is secure. You will find out how to test, purchase, 
install and use a thawte Digital Certificate on your Apache web server. Throughout, best practices for set-up are 
highlighted to help you ensure efficient ongoing management of your encryption keys and digital certificates.

http://www.dinclinx.com/Redirect.aspx?36;4175;25;1371;0;5;946;e13b6be442f727d1
------------------------------------------------------------------------