Re: checking web applications for exploits

[Harshvardhan Parmar <harshvardhan.p () paladion net>]

Adding to what everyone has said and summarizing thing..

You would definitely want to fix SQL Injection, Cross Site Scripting
(XSS) & Cross Site Request Forgery (CSRF).
For the most part, SQL Injection can be taken care of by properly
validating user input values. However, there are a couple of advanced
attacks that can bypass input filtering. Using parameterized queries
is the surest way of preventing SQL Injection attacks on your
application.

XSS allows an attacker to run his scripts on the victim machine and
your web application is the medium to get that script across to your
users. XSS can be prevented by sanitizing user input. However,
depending on your application, there might be a couple of meta
characters that you may not be able to filter and hence, a better
solution is to escaping [output encoding] user input values.
Example: If a user gives an input like "My name is <John Doe>", you
HTML encode the meta characters < & > to &lt; and &gt; respectively.

CSRF makes use of the fact that a cookie for any domain will by
default accompany any request directed for it's domain. In order to
prevent CSRF you need to ensure you have a token, different from your
session token, which is passed with every request and is NOT a part of
your cookie.

Apart from these, follow general best practices like:
1. Always validate on the server and do not depend on client side validation
2. Ensure that a fresh session token is assigned on authentication,
the session token is invalidated properly on logout & there is a
timeout in place. Set proper cookie attributes (Path, Domain, Secure &
HTTPOnly).
3. Use an encrypted channel (TLS)
4. Use a CAPTCHA for publicly available forms (Login & Registration
pages) to prevent an automated attack
5. Use updated, patched versions for your servers

Reference Reads:
SQL Injection - http://www.unixwiz.net/techtips/sql-injection.html
SQL Injection prevention -
http://www.wwwcoder.com/main/parentid/258/site/2966/68/default.aspx
XSS - 
http://h30499.www3.hp.com/t5/The-HP-Security-Laboratory-Blog/Cookie-Stealing-With-Cross-Site-Scripting-Explained/ba-p/2408250
Output Encoding -
https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#Escaping_.28aka_Output_Encoding.29
CSRF - http://www.cgisecurity.com/csrf-faq.html
CSRF prevention -
http://www.codinghorror.com/blog/2008/10/preventing-csrf-and-xsrf-attacks.html

Hope this helps.

Cheers
Harsh

On Tue, Jul 26, 2011 at 1:10 PM, Maarten Hoogveld <m.hoogveld () elevate nl> wrote:
> 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
> ------------------------------------------------------------------------

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