Get Ready for Web Application Security Testing

Editor's Notes

• #22: Injection flaws occur when user supplied data, is sent to an interpreter as a part of a command, query or data. The main issue here is that user input is not sanitized, and is embedded in pre-existing commands. Injection flaws can occur in: SQL queries (known as SQL Injection) Server Side Includes (execute commands on the web server) LDAP queries – used to bypass authentication
• #23: SQL Injection occurs when user input is embedded as-is inside a pre-built SQL query. For example: Let’s assume that our web application receives a product ID as input, and presents that product’s page. The SQL query looks like this: “ Select * from products where id=‘” + $REQUEST[‘id’]; You should note, that the query is basically a text string, and user input is concatenated to it. In this example, the user string is surrounded by apostrophes. Let’s take a look at what will happen if we submit the product ID value of ‘ or ‘’=‘ The query will be: SELECT * from products where id=‘’ or ‘’=‘’; You should pay attention to the fact that the WHERE criteria here is basically a Boolean TRUE. Since the results of this query matches every entry in the database, all the products will be returned.
• #24: Let’s take a look at how SQL Injection can assist a hacker to bypass the login mechanism of a banking application: - First, in order to sense that SQL Injection is possible, the hacker will injection the character apostrophe (‘), as the user name
• #25: This yields a very informative SQL error message, which helps the attacker to devise the next phase of the injection
• #26: Now, the hacker attempts to send the username: ‘ or 1=1— Note: the apostrophe is used to close the string context in which our input is embedded in 1=1 is a Boolean TRUE -- is used in MS SQL to comment out everything after the – sign, so we don’t have to worry about the rest of the SQL query
• #27: After sending this SQL injection payload, we will be logged into the application, as the first user in the user's table - without having to supply actual credentials.
• #28: Comments at one level can be command at another
• #30: A Cross Site Scripting attack, attempts to echo back a malicious script in the HTML returned from a trusted site. Since the script is echoed back from a trusted site, it runs in the context of that site. The implications of XSS are: Stealing HTTP session tokens Page content may be compromised (this may include “local” site defacement, or hijacking of the browser’s session using scripting) Future pages may be contaminated as well (by hijacking the session)
• #31: Let’s take a look at the chain of events during a XSS attack The attack creates and sends the victim a link to bank.com (a trusted site). The link contains a search string (or any other string that is echoed back), which contains a malicious JavaScript code The victim, clicks on this link, since he/she trusts the bank.com web site The bank.com web application, echoes back the malicious JavaScript code inside the response page. This JavaScript is executed in the security context of bank.com, since it is echoed by from that site. This means that it has access to DOM elements belonging to this domain/session The malicious script, sends the current cookie and session information, without the victim’s consent, to the evil.org web site, where the hacker is waiting for it.
• #32: Let’s take a look at the following banking web site – this site contains a search function, that allows users to search the site for specific text. If we type the string “asdf”, the response to the search will contain that string, inside the results page, in what we call “free HTML context”. What will happen if instead of typing “asdf”, we will type some JavaScript code? Let’s try to type the following JavaScript code: <script>alert(document.cookie)</script>
• #33: As you can see – the piece of JavaScript code that we wrote, was echoed back by the site’s search function – since it was returned from the banking application, it had access to the Document Object Model (DOM), and could access the current session cookie. In this situation, I myself planted this JavaScript code in the web page, but in a XSS attack, it is the attacker who creates a link that contains the malicious JavaScript, and then sends this link to the victim. When the victim clicks on the link, the malicious JavaScript will be echoed back from the trusted site.
• #34: In several scenarios, it may be possible for an attacker to manipulate the web application to disclose a resource such as a sensitive file. This can occur by either guessing a common file name and location and attempting to request it, or by manipulating a parameter value that is used to access a file, as will be seen in the next example. The implications of Insecure Direct Object Reference is usually information leakage or access to sensitive resources.
• #35: In this example, we see that a web application that uses a parameter called “content”, which points to the contents of the page to be displayed. An attacker might attempt to manipulate the parameter value, from “business_deposit.htm”, which is the valid page, to some other file – for example, the Boot.ini which is a system file.
• #36: The attempt failed, and the system disclosed that it only allows parameter value (file names) that end with either txt or htm as their file extension. Let’s try a little trick called “Poison Null Byte”, we’ll write the file we actually want to open which is Boot.ini, but append a NULL character and the extension the application is looking for (in this example .htm)
• #37: Bingo! – we managed to circumvent the file extension validation, and open a sensitive system file. Using this technique, we can manipulate the application to hand us the contents of other, more sensitive files, such as databases, customer files, etc.
• #43: Thank you!