Re: checking web applications for exploits

[Maarten Hoogveld <m.hoogveld () elevate nl>]

Just a small addition. Using both addslashes and mysql_escape_string
would prevent query injections it's a bit double. Quotes (and
backslashes) are escaped by both functions adding three in total. Eg:
[they're] -> [they\\\'re]
Also the use of mysql_real_escape_string is preferred to
mysql_escape_string (see php.net)
When using LIKE in queries, don't forget to escape '%' and '_'.
Personally I use intval() a lot when it concerns integer values. This
might prevent query errors when characters are passed as parameter
values in the request which would otherwise wind up in the query. This
is not more secure by the way, unless you output query errors which
you shouldn't :)

Maarten Hoogveld
Elevate BV



On Mon, Jul 25, 2011 at 10:04 PM, Matthew Finkel
<matthew.finkel () gmail com> wrote:
> 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
> ------------------------------------------------------------------------

------------------------------------------------------------------------
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
------------------------------------------------------------------------