Web Application Security

SQL injection is  serious business , but you shouldn't be overwhelmed by the thought of defending against it. Follow these simple steps to keep attackers' eyes and fingers out of your databases. Ensure that only generic, nondescriptive error message or HTTP 500 pages are displayed to users. Never give away database metadata like table names or application source code snippets in error messages.  Validate simple input types like credit card numbers or postal codes with regular expression. If the input doesn't match the expected value, return an error to the user ( a generic, nondescriptive error!) and don't execute the database query. Always check to make sure that the input matches a good , valid pattern ( for example , whitelist pattern matching) rather than whether it matches a bad,invalid pattern(for example,blacklist matching). Whitelist validation defenses are usually much more resilient to newly discovered attack techniques.  If the input is a date or numer...

Sandcat is multi-process remote web application security scanner. It maps the entire web site structure ( all links , forms , XHR requests and other entry points) and tries to find custom,unique vulnerabilities by simulating a wide range of attacks/sending thousands of requests (mostly GET and POST).  It also tests for SQL Inection, XSS, File inclusion and many other web application vulnerability classes.  Sandcat's code scanning functionality automates the process of reviewing the web application's code .  Source : CEH Lectures ...

The problem as I see it..... Where to start? Let me start by telling you that most of the books you read are wrong. The code samples you copy of the internet to do a specific task are wrong (the wrong way to handle a GET request), the function you copied from that work colleague who in turn copied from a forum is wrong (the wrong way to handle redirects). Start to question everything. Maybe this post is wrong this is the kind of mindset you require in order to protect your sites from XSS. You as a developer need to start thinking more about your code. If a article you are reading contains stuff like echo $_GET or Response.Write without filtering then it’s time to close that article. Are frameworks the answer? I think in my honest opinion no. Yes a framework might prevent XSS in the short term but in the long term the framework code will be proven to contain mistakes as it evolves and thus when it is exploited it will be more severe than if you wrote the code yourself. Why more ...

Some web applications use SSL to protect the application's authentication page,because this prevents the user's password from traveling in the clear and thus protects the password from eavesdropping attacks, but then they don't use SSL to encrypt the rest of the application's traffic. This largely renders the password orrelevant, however,because the attacker can still snoop on the unencrypted traffic in order to steal the session ID and impersonate the user that way. If you're going to use SSL at all,you really want to use it for your whole application. Resource : Web Application Security, A beginners Guide , By : Bryan Sullivan & Vincent Liu

Firesheep is a tool that highlights the weakness of unencrypted cookies. The use of unencrypted cookies is such a serious security vulnerability that they have led some security activists to exploit them on purpose, merely to demonstrate how insecure they really are.  Firesheep is a browser extension for the Firefox browser, which literally makes it point-and-click easy for someone to steal session IDs from certain popular social networking web sites and impersonate other users. Firesheep works by packet sniffing. It watches for the unencrypted session ID values stored in cookies to pass by on whatever section of Internet traffic it can see,captures those values, and presents them to the attacker within the attacker's web browser along with the victim's name. When the attacker double-clicks on a victim's name, Firesheep substitutes the stolen session ID value in place of its own,which allow the attacker to impersonate the victim. There is no way of knowing how many vic...

Cross-site scripting is without a doubt the worst-named web application vulnerability in the world  . So many people have trouble understanding what XSS is just because of its awful name. One time , I was at a developer conference, and between sessions I had struck up a conversation with a programmer. We started talking about web security in his application, and I asked him what he was doing about cross-site scripting. he answered, "Oh , we don't have to worry about that. we don't use cross-site scripting." I explained to him that XSS isn't something that you use; it's something that attackers use against you!  By the end of our talk, he was straightened out, but I can't help wondering how many more programmers like him are out there who are ignoring XSS because they think it's a feature that they're not using. If it had been up to me, I probably would have called it "JavaScript Injection," which I think is a much more accurate de...

 Small sample of attacks in the first half of 2011 alone includes: The SQL injection attacks on the Sony Music web sites in MAY 2011 by the LulzSec organization.While unconfirmed by Sony, it's also believed that SQL injection vulnerabilities were responsible for the attacks against the Sony PlayStation Network and Qriocity that leaked the private data of 77 million users and led Sony to shut down the services for over a month. The overall cost of this breach to Sony has been estimated to exceed 171 million dollars (US). A cross-site scripting vulnerability in the Andoid Market discovered in March 2011 that allowed attackers to remotely install apps onto users' Andiod devices without their knowledge or consent.  The Attack of information security firm HBGary Federal in Feb. 2011 by the hacker group Anonymous. Another simple SQL injection vulnerability in the www.hbgaryfederal.com website,combined with a poorly implemented use of cryptographic hash function, enabled Anonym...

Never trust the user!  Validate all input coming from a user. This includes any part of an HTTP request that you're processing: the header names and values, the cookie names and values, the querysting parameters, web form values, and any other data included in the message body.  Always use whilelist input validation to test input; that is, test whether an input does match an expected good format and reject it if it doesn't. Avoid blacklist input validation; that is, testing whether an input matches an expected bad format and rejecting it if it does.  Never perform validation just on client side - an attacker can easily bypass these controls. Always validate on the server side.  Use regular expressions for more complicated validation logic like testing e-mail addresses. Unless you're a regex expert, also consider using regex from one of the public databases such as regexlib.com or a commercial regex ...