by Atul GaikwadNow-a-days, application developers have become smart enough to take care of the different vulnerabilities which may affect their application. But sometimes, due to time constraints or maybe plain laziness, they fix issues only for the instances reported in an audit and do not fix them throughout the application. This would allow an attacker to craft an exploit for vulnerable instance which may cause severe damage and can also blemish the brand.In a recent Black Box Application Security Assessment, we came across an interesting exploit which was an outcome of multiple vulnerabilities. The scenario was as follows:The application had a 'Forgot Password' page which asked the user his/her username and upon submission of a valid username, it served the next page asking for the answer to a security question. After submitting the correct answer, an e-mail containing a link to reset the password is sent to the user.The application was safe against SQL injection except for one instance; this was the 'Forgot Password' page. We could reach the page asking the security question for the first user entry present in the database after carrying out an SQL Injection attack on the username input field present on the 'Forgot Password' page. Breaking the security question was not an easy job and even if we could break it, the link to reset the password would be sent to the valid user's e-mail id. So, the vulnerability here was SQL Injection and though potentially lethal, it was difficult to exploit.While testing, we found that the application was secured against Cross Site Scripting (XSS) attacks. But, after performing SQL Injection, we found that the application serves the page containing the security question with text in the format of "Dear <username>", where <username> was the value entered in the username field on the previous page. That meant the application could be vulnerable to the XSS as well. So now, SQL Injection, which seemed relatively less harmful because of the difficulty of exploit, could result in another possibly high-risk vulnerability.When the query fragment used for SQL Injection is followed by a script, say, "<script>alert("XSS");</script>" in the username input field, an alert window pops up with the text "XSS". Thus, the application turned out to be vulnerable to XSS as well.Now, we started thinking on how this SQL+XSS vulnerability can be scaled up further. For this, we thought of inserting an HTML code in the username input field which would get reflected on the next page and this would result in a page which would ask the victim to enter the credit card details like credit card number, CVV, Expiry date. To take advantage of the user's fear, we put the message "We have observed some suspicious activity in your account. Please provide us the necessary information to verify the same:"But, still there is one hurdle. The application welcomes the user saying "Dear <username>'" and the <username> will also contain the SQL query fragment. A vigilant user may find this kind of message suspicious.Now what?The challenge was to hide the SQL query from the user. Here, the HTML comment tag (<!-- comment -->) came in handy. We crafted a SQL query such that only a "Dear User" message would be displayed to the victim and the SQL query fragment would be commented out.This means now, we are ready to steal sensitive data, in a manner similar to a 'phishing' attack, but by using the valid site.The website, with the crafted page, is shown in the following screenshot:There is a PHP code used at the back-end for capturing the values of the parameters sent by the victim. The attacker's e-mail ID is mentioned in the code. Hence, on clicking SUBMIT the credit card details will be sent to the attacker's e-mail ID.This attack can have variations and the data to be stolen is up to the attacker's creativity and ingenuity.
