An approach for Security Testing of Web Applications

posted in: Security | 0

Summary:

Description: Introduction

As more and more vital data is stored in web applications and the number of transactions on the web increases, proper security testing of web applications is becoming very important. Security testing is the process that determines that confidential data stays confidential (i.e. it is not exposed to individuals/ entities for which it is not meant) and users can perform only those tasks that they are authorized to perform (e.g. a user should not be able to deny the functionality of the web site to other users, a user should not be able to change the functionality of the web application in an unintended way etc.).

1. Password cracking:

The security testing on a web application can be kicked off by “password cracking”. In order to log in to the private areas of the application, one can either guess a username/ password or use some password cracker tool for the same. Lists of common usernames and passwords are available along with open source password crackers. If the web application does not enforce a complex password (e.g. with alphabets, number and special characters, with at least a required number of characters), it may not take very long to crack the username and password.

If username or password is stored in cookies without encrypting, attacker can use different methods to steal the cookies and then information stored in the cookies like username and password.

2. URL manipulation through HTTP GET methods:

Check if the application passes important information in the querystring. This happens when the application uses the HTTP GET method to pass information between the client and the server. The information is passed in parameters in the querystring. The tester can modify a parameter value in the querystring to check if the server accepts it.

Via HTTP GET request user information is passed to server for authentication or fetching data. Attacker can manipulate every input variable passed from this GET request to server in order to get the required information or to corrupt the data. In such conditions any unusual behavior by application or web server is the doorway for the attacker to get into the application.

3. SQL Injection:

The next thing that should be checked is SQL injection. Entering a single quote (‘) in any textbox should be rejected by the application. Instead, if the tester encounters a database error, it means that the user input is inserted in some query which is then executed by the application. In such a case, the application is vulnerable to SQL injection.

SQL injection attacks are very critical as attacker can get vital information from server database. To check SQL injection entry points into your web application, find out code from your code base where direct MySQL queries are executed on database by accepting some user inputs.

If user input data is crafted in SQL queries to query the database, attacker can inject SQL statements or part of SQL statements as user inputs to extract vital information from database. Even if attacker is successful to crash the application, from the SQL query error shown on browser, attacker can get the information they are looking for. Special characters from user inputs should be handled/escaped properly in such cases.

4. Cross Site Scripting (XSS):

The tester should additionally check the web application for XSS (Cross site scripting). Any HTML e.g. <HTML> or any script e.g. <SCRIPT> should not be accepted by the application. If it is, the application can be prone to an attack by Cross Site Scripting.

Attacker can use this method to execute malicious script or URL on victim’s browser. Using cross-site scripting, attacker can use scripts like JavaScript to steal user cookies and information stored in the cookies.

Many web applications get some user information and pass this information in some variables from different pages.

Attacker can easily pass some malicious input or <script> as a ‘&query’ parameter which can explore important user/server data on browser.

5. URL session variables and HTTP_REFERER

Because the web is a stateless environment, there are several mechanisms that people use to track users as they move through an application. The most common mechanism is to set cookies with user ID and session ID, then track the user based on those cookies as they use the application. But, in the cases where cookies are not acceptable, the session information will typically be passed in URL variables, which can expose some not so obvious risks.

In some cases, developers will create the session state architecture on their own, but when developers use ColdFusion session state management they inherit this system from ColdFusion. ColdFusion provides web developers with the ability to store values on the server side that are unique to a user’s “session” at the site. ColdFusion relies on two “token” values passed between the client browser and the ColdFusion Server to be able to distinguish one user’s session variables from another’s. These two token values are named “CFID” and “CFTOKEN”, and together represent a unique visitor’s session.

If session variables are being used by an application, ColdFusion’s default behavior is to issue two browser cookies with numeric values named “CFID” and “CFTOKEN”. For each subsequent trip to the server, ColdFusion uses these cookies to look up state information stored on the server. However, for sites which do not wish to use or rely on cookie browser support, the “CFID” and “CFTOKEN” values can be appended to the URL as variables using the URLTOKEN variable. ColdFusion will also automatically find and use these values.

Under normal circumstances, passing session information on a URL is not a problem, but there are potential risks that developers need to avoid when they code applications that pass session variable information, or any sensitive information on a URL. In general, you should avoid sending any sensitive information on a URL string out of your application:

* Passing session ID data out of the application on the URL. The obvious mistake is to append the session information to a URL that is linking out of the application to another site. This will transfer the information to the other site where it can potentially be captured and used to mimic the user for unauthorized access.
* Passing session ID data out of the application through the HTTP_REFERER header variable. Every HTTP request (hyperlink) includes an HTTP Header with a set of environment variables. One of the variables is “HTTP_REFERER.” This variable contains the URL that was used to access the page that is being linked from. So if you are navigating through an application with URL based session variables then you click a clean link from the application to another site, the HTTP_REFERER variable may contain the URL with the session data. As with the first example, this could then be used to spoof the user and return to the site for unauthorized access.

Addressing URL Session Variable Security Risks

There are several different ways to help protect against the potential risks described above:

* Don’t pass session ID information on the URL. If you use cookies instead this will prevent the problem of accidentally passing session ID information out of a site.
* Link to pages leaving an app with forms. You can link to pages that have links out of the application using forms instead of URLs. When you link to a page with a form, passing the session information in a hidden form field, the HTTP_REFERER variable that is created on the next link will not contain the session information.
* Use other data to check users during sessions. Most systems will have a user ID that is unique for the user and a session ID that is unique for the session. In addition, you can use an IP address as another environment variable not based on the URL to help to confirm that your application is in fact talking with the right user. (If you are using ColdFusion session state management you cannot use this technique.)
* Keep session timeouts short. Typically sessions are designed to “timeout” after a certain period of inactivity. It is a good idea to keep the session timeout length short (e.g. 10 -15 minutes) so that session IDs become invalid faster, which will leave less time for possible unauthorized access without authentication.
Important: During security testing, one should be very careful not to modify any of the following:

* Configuration of the application or the server
* Services running on the server
* Existing user or customer data hosted by the application

Additionally, a security test should be avoided on a production system.

Conclusion:
The purpose of the security test is to discover the vulnerabilities of the web application so that the developers can then remove these vulnerabilities from the application and make the web application and data safe from unauthorized actions.

Next Post

Leave a Reply