Contact us for your penetration testing needs 1-866-PLYNT-24    |   Contact Us   Plynt UK Website  
Click to get Security Testing Quote

Cross-Site Scripting Attack through SQL injection

by Atul Gaikwad  | 10 Jan 2012

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

Require Security?...Then Think Security

by Ashish Rao  | 05 Jan 2012

So much has been written and documented about securing web applications that it should be a simple process by now. However, as it still stands, it is an overload to development teams across the globe. I doubt whether “security” falls within the "requirement specifications" of any application. Not everyone treats security as a requirement. It is usually an "add-on" or “patch-up”, which is injected later on into the application; hence, the overload in terms of development effort and time. In such a process, even if a single security patch is missed, the overall security of the application can go for a toss - paving a way for the "Hackers"!

Treat security as a "requirement"… and I am sure it will make a big difference…

It is necessary to think about security at each and every stage of the application development process. It is just like cooking food while at the same time keeping health concerns in mind.

Developers often complain, "I don’t know anything about application security".

I agree, not all of us are security experts but we all can, of course, think about "security". One can certainly consult security experts and involve them during the development process.

For instance, if you were to buy a new car and suddenly thought "security" should be one of the key aspects to look for, I am sure that you would probably check the number of features related to security e.g. locking or any tracking feature available. You would try and evaluate all its features with respect to security. You would even call up your friend to verify whether you are choosing right or whether you should be looking for some other safety feature. You would also take an opinion about all the existing features it offered.

It is the same in the case of web applications. Think about security for each and every feature that you develop. You can document whatever is not feasible to be remediated (or developed) immediately. Call your friends - i.e. security experts like “Plynt” to analyze these areas and features. It is very important that you involve security experts either during the development process (on an ongoing basis) or at the end of it. You must discuss all the application features thoroughly with them, in the same way that you would explain everything about your car to your friend; because the more you talk about the application and its controls, the more you will hear about security from the experts.

Familiarizing the security experts with all the features, entry points, integrations, add-ons, etc. is crucial. You may also discuss the security controls that you have already implemented in the application. I am sure if you are conscious about security, you would be proactive toward security controls right from scratch. The security experts will verify them and test their effectiveness against the latest attack vectors.

The security experts will carry out a complete security test based on the information in hand and make you understand what kind of security controls must be implemented in which area in the application. Such a comprehensive security test will also ensure that nothing is missed and your security requirement will also be met.

You can then have a safe drive…for a long long time :)

Ten Questions to Ask Before You Jump into Code Reviews

by Priya Gangwani  | 07 Sep 2011

Someone once said to me, ‘We need to ask a million questions to understand the application!’, and that had me come up with a short list of ten questions (yeah, you heard it right!) that a code reviewer can ask to get a hang of the application’s context.

Do I hear you ask, ‘what is a context’? Context, in this sense, is the functionality of the application being reviewed. Suggesting military standard security mechanisms for an e-book application would be useless. Understanding the context of an application gives an overall idea of the impact to the company if its data is compromised. This is what defines security. 

As the OWASP Code Review guide rightly says, ‘Context is the “Holy Grail” of secure code inspection and risk assessment’. Code review is not just about reviewing code. It’s also about ensuring that the code protects the assets and confidential data that the application is entrusted with. If one understands the business correctly, then creating a threat profile and other things that follow is merely child’s play!

You may have your own set of questions, but listed below are the ten questions that should find a place in your ‘Ask the developer’ checklist.

  1. What is the purpose of the application? From what the application does to how the business benefits from it as well as the nature of the application (small business marketing software or enterprise-level applications), examining every aspect provides a new perspective. All these perspectives go a long way in defining security for a particular application.
  2. Who are its real users? Are they internal or external users? If both, are they authenticated differently? This question refers to the intended users of the application. Also, it should address the kind of users they are i.e. if they are human & technically efficient as well (the more crazy it gets, the merrier it is for us).
    Also, one often sees that if an application is meant for internal users, security is often not considered very critical. Paradoxically, most hacking attempts occur from within an organization. The idea behind such questions is to figure out the differences between these users from a security standpoint and how they are authenticated in the application. Do they use AD or LDAP to authenticate internal and external users? Does the application distinguish between internal and external users?
  3. What should be considered ‘CONFIDENTIAL’ data/assets in the application? This is most critical to security and therefore knowing the answer to this would help assess the right risk to the application. What is the impact if the information is compromised in any way?
  4. What are the different environments in which the application is deployed? Is the code given for review in the same manner as the one deployed in production? Usually, an application is deployed in the test environment along with the production environment. It is always good to know how it is deployed and if there is any difference between the various environments. The difference might be with regard to integration with other applications, presence of a web application firewall, etc. Another critical thing to be confirmed is the authenticity of the code shared for review. Is the code base complete and same as that deployed in production? One often comes across developers who don’t share configuration files, property files and the like, thinking that these might not be required to assess the security of the application.
  5. How important is this application to the enterprise? This question may seem irrelevant but it is not so. Given this perspective, the reviewer will be in a better place to suggest mitigation techniques and counter measures to the vulnerabilities identified during code review. The cost of preparation if any and the business impact derived by the exploitation of the vulnerability are two key factors that should be kept in mind before suggesting solutions. Now, you do want them to implement your suggestions and fix their application, don’t you?
  6. Is the application integrated with other applications in the company? Is the data coming from somewhere and/or going somewhere? It is critical to understand how the application interacts with external entities. Another critical understanding would be to identify trust levels that represent access rights granted by the application to external entities like web services. A trust boundary exists when a user accesses or enters data into the application, and also when an application interacts with the database.
  7. What are the entry points and exit points in this application? Entry and exit points define a trust boundary. This knowledge allows the reviewer to assess attack surfaces & come with possible threats to the application. Entry points, for example, can be:
    • Browser input
    • Cookies
    • Property files
    • External processes
    • Data feeds
    • Service responses
    • Flat files
    • Command line parameters
    • Environment variables
    Exit points, for example, can be:
    • The Search page that writes the client’s search string and its corresponding results.
    • Error Page
    • Information Page
  8. Are audit trails and logs pertaining to the application maintained somewhere? Audit trails and logs are a form of documentation, which help in reviewing various activities undertaken by various users. These can provide a means to accomplish several security-related objectives, including individual accountability, reconstruction of events (actions that occur on the computer system), intrusion detection, and problem analysis as well as evidence of the correct processing regimes within a system.
  9. Are there any security measures in place? ‘Is there something that really needs to be secured apart from ensuring that the right users access the right data?’, ‘Does the application prevent external attacks like the submission of special characters to the application’, ‘Is the application protecting the right kind of data in the right manner?’, ‘Are there roles and privileges, which define what portion of data is accessible to which user?’, ‘What operations should an authorized user be able to perform on the data?’ and ‘Is the application defensive against attacks?’ are some of the questions that are answered here!
  10. What is the architecture of the application? This should leave the reviewer with a good knowledge of the key technologies used, application frameworks, servers (database server, web server, etc.), application tiers, software used (along with the version number), and type of application (data-intensive application, service-oriented application, etc.). Gathering maximum information about the operational environment of the applications helps in assessing the right security risks. Developers should share DFDs, Use Case diagrams, Process View diagrams and others of the same kind to enable better testing.

Last but not the least, make sure that some developers are always available in case you get lost in the maze!

Forgot Password Best Practices

by Sourabh Saxena  | 01 Sep 2011

The Standard Best Practice followed by Gmail and other public websites are as below:

  1. Ask the username and/or a Custom Security question
  2. Display a Captcha, after successful verification of username and/or Security Question
  3. Send a link to the user’s registered email address. The link should have random token associated with it
  4. The link should be short-lived, one time use only, and SSL enabled.
  5. Once the user’s resets the password, the link should no longer be usable.

For most applications the above solution should work fine. What the SSL enabled link does is that it never exposes the user’s password to an external entity like Yahoo, Gmail or hotmail, and it never resets the password automatically.

We were brainstorming over this solution, and one of the concerns was that we are putting our trust on an external entity (like a yahoo, gmail or hotmail) to hold the key to reset our account passwords, albeit for a short period of time. For applications that hold critical or sensitive data and that still need to implement a web based forgot password solution, this may not be an acceptable solution.

We came up with a few enhancements to the above standard solution, here is how it goes.

The Plynt Secure Forgot Password Solution

  1. Provide a publicly available Password Reset page over SSL, which asks for the user ID and 3 non guessable hint questions along with a CAPTCHA.
  2. After a successful verification, allow the user to choose/enter a 6-character Temporary Authorization Pin/Token
  3. Email another short lived SSL enabled tokenized URL to the user’s email address.
  4. On Clicking this tokenized URL, the user should be asked to enter the 6-character Authorization Pin/Token and the new password.
  5. Expire the tokenized URL and Temporary Authorization Pin/Token
  6. Notify the user that the password has been changed.
  7. Force the user to change new password on the first login after resetting the password.

The above solution has all the benefits of the standard solution, in addition to that, we are protecting against a scenario where external entities like gmail, yahoo or hotmail accounts are compromised or data within them are sniffed over the network (traffic over HTTP).  We protect this by adding a 6-character Temporary Authorization Pin/Token that the user enters on the web application’s forgot password page, and hence is only known to the user. Without this token, the short lived SSL enabled tokenized URL will not be able to reset the password.  Thus we have fulfilled both “What you know” and “What you have” principles of security.

Earlier Posts

Movable Type Appliance - Powered by TurnKey Linux