By Christian Malatesti

Web applications can be like Pandora’s Box, but with more than just troubles. This article takes a look at a few of the preferred practices used by hackers to circumvent the security of Web applications.

How many times have you waited for the launch of the next cool Web application that promises to end your worries and make your life easier? With you hanging in the fine balance of enthusiasm and rational thought, let’s take a closer look at Web applications.

Web applications can be like Pandora’s Box, releasing all manner of evil into the Web world, but with more than just troubles – they are often personal favorites of hackers. Ebanking applications, online retailers, and government websites, among others, have been prime targets in the past with hackers stealing sensitive information and causing permanent damage to reputations. So before opening your Pandora’s Box, be aware that there may be evil inside.

Let’s now dig into the evil and show a few of the preferred practices used by hackers to circumvent the security of Web applications:

1. Session hijacking
2. SQL injections
3. Cross-site scripting (XSS)
4. Cross-site request forgery (XSRF)

All of these hacking techniques are listed in the OWASP Top 10 most common Web application security vulnerabilities.

Session hijacking
Web applications use a technique called session management to “remember” the identity and activities of users. Typically, Web applications use session tokens such as cookies, URL base and custom headers, and hidden form fields to accomplish this purpose. A session token contains a unique, randomly generated session identifier (typically alpha-numeric) that is assigned to a user after he has successfully logged into the application. The session identifier is used as valid authentication “proof ” for the subsequent communications between the server and the user. Session identifiers usually last until the user logs out or the session times out.

Although session tokens are very convenient and facilitate the user’s experience with an application, if not properly managed, they can be a mouth-watering target for hackers. For instance, by stealing the session ID of another user, a hacker would be able to subvert the identification mechanism, impersonate the user, and have full access to his data and private information. This can be accomplished in many ways. Let’s take a look at a few.

Session prediction and brute force
Many Web applications use customized algorithms to generate the value of the session IDs. Quite often these algorithms create predictable session IDs by incrementing the previous value by 1 or by a time interval. At this point, a hacker would have to gather a sample of session tokens and analyze them in order to discover common patterns and reverse engineer the session ID generation algorithm. A quick way of gathering session IDs is to run free automated tools such as WebScarab. Typically, the session ID is created the first time a user visits the website, for instance, when the user first accesses www. mytarget.com. The session ID is then stored in a cookie or hidden field in this example. The session ID has been created, but it does not identify an established and authenticated session yet. Once the user authenticates to the website, the session ID is assigned to the user and it identifies the user session. Let’s now see a practical example.

We collect a sample of 1000 session IDs (the column Value in Figure 1) using WebScarab to identify any common patterns.

By carefully analyzing the values collected, we can discover a

common pattern in the session IDs:

34xxxx5x501xxxx7

where the Xs represent values that it was not possible to identify a predictable pattern. Therefore, they remain unknown. Additionally, the next graph (Figure 2) shows the level of randomness of the session IDs value generation scheme. Since the values are very close to one another, the level of randomness is very low. Therefore, we can conclude that the algorithm used to produce session IDs follows a repeatable and predictable pattern.

At this point, a hacker could try to predict the remaining values by performing further statistical analysis on a larger sample of session IDs or perform a brute force attack. A brute force attack involves trying all possible combinations of values until a valid SessionID is found. However, even with a larger sample, the attacker will have to brute force some characters of the session ID.

Let’s now brute force the remaining elements of the pattern

earlier identified:

The string 34xxxx5x501xxxx7 is 16 characters in length of which 7 characters have been identified: 3,4,5,5,0,1, and 7. Therefore, we need to brute force the remaining 9 characters (the Xs).

Given the alphabet (10 numbers = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9}) and the string length (16), the possible combinations for the remaining 9 characters can be calculated as follows:

Using WebScarab, we were able to collect 1,000 session IDs in approximately 2 minutes. Therefore, in approximately 4086 minutes -> 68 hours-> ~3 days, we can brute force the 2,042,975 combinations.

Many automated scripts and tools can be used to perform this type of attack and send thousands of requests with session IDs to the website such as those below:

http://www.mytarget.com?ssID=34125759508641907

http://www.mytarget.com?ssID= 34110657500865217

http://www.mytarget.com?ssID= 34464855501123677

http://www.mytarget.com?ssID= 34225756509076477

http://www.mytarget.com?ssID= 34098754500044587

….

If we get lucky, and we guess the sessionID assigned to a legitimate user connected during the time frame of the attack, we will be able to impersonate the user and access the website, bypassing the authentication.

Session fixation attack

The session fixation attack is a more sophisticated attack compared to session brute forcing. In this attack, the hacker prepares a valid session ID and then phishes a legitimate user of the website to make him login to the Web application using a session ID he prepared for him. While the legitimate session is valid, the attacker can access the website providing the same session ID, thus circumventing the authentication mechanisms. Let’s observe the steps of this attack.

Step 1: The hacker obtains a valid sessionID by simply visiting the targeted Web application. For this example, we can use one of the session IDs collected in the previous attack such as 34098754500044587. Step 2: The hacker prepares a phishing email to entice visitors to click on a URL leading to the target website:

Dear Customer

,

We recently observed suspicious activities for an amount of $1,520 related to your credit card. We strongly recommend you to login into your account to ensure the validity of such activities. To login into your account, click on the following link:

http://www.targetwebsite.com/login.asp?ssID=34098754500044587

Regards, Customer Service

Note that the URL already contains the embedded session ID collected during the first step.

Step 3: The victim clicks on the link leading to the login page of www.targetwebsite.com. If the session management of the application is not properly implemented, the application will recognize that a session ID has already been created so it will not create a new one:

Hopefully, the user logins and the Web application validates and assigns the fixed session ID to the user.

Step 4: After the user has logged into the fixed session and before he has logged out, the hacker must access the website at the following URL: http://www.targetwebsite.com/welcome. asp?ssID=34098754500044587.

How would the attacker know when to click on the link in order to find an unexpired session? An attacker can use one of the many commercial and free email and hyperlink click-through tools available online to receive notifications of when the victim opened the email and clicked on the malicious hyperlink.

Step 5: With this information, the attacker clicks on the link above. The website recognizes the session ID as valid and authenticated so it leads the attacker to the welcome page bypassing the login page. The attacker can now browse the website impersonating the legitimate user.

The vulnerabilities exploited in those two examples reside in the session management of the Web application. When performing Web application hacking tests, a professional should check that the following controls are in place to mitigate the risks that the application be compromised by those vulnerabilities:

• Analyze the randomness of the session ID generation algorithm. The algorithm should not be linear or use predictable factors to compute the session IDs so that the session IDs will be as random as possible.

• Session IDs should be 1024 characters in length. Further, the set of characters used to compose the string should include numbers, letters (distinguishing uppercase from lowercase). By doing so, the resulting space of combinations would be so large as to significantly discourage session brute force/prediction attacks.

• Ensure that the Web application creates and assigns the session IDs after the user has logged in. This will prevent attackers from analyzing the randomness of the session IDs.

• Ensure that the Web application ignores session IDs provided by the user’s browser. The Web application should always generate new sessions and discard those provided by the user.

• Ensure that the session tracks user browser characteristics such as browser type, source IP and time of when the first connection was made. The session ID and browser characteristics should be stored on the server so that the Web application can compare this information with that provided by the user’s browser. Multiple and simultaneous connections with the same sessionID but diverse browser characteristics may indicate the occurrence of a session impersonation attack.

• Ensure that the Web application does not allow two contemporary connections with the same session ID. When this occurs, the user connected first should be notified that another connection attempt with the same session ID has been made.

• Ensure that sessions expire when user logs out, time out or after session is idle for 10 minutes. Ensure that lockout policies are implemented to lockout users after three or five password errors.

• Ensure SSLv3 with minimum 128 bit keys is used to protect the confidentiality of the communication.

• Ensure the owner of the Web application performs due diligence in educating the customers to recognize phishing techniques.

SQL Injection

SQL injection is an attack that exploits inadequate input validation controls in a Web application. SQL injection is a simple yet powerful attack that could allow an attacker to retrieve sensitive data from a database, execute operating system commands, and read/modify the local file system. This attack is based on the manipulation of SQL queries, SQL being the programming language used for interacting with databases. Since the SQL language has many “dialects,” the syntax of a query in SQL can vary based on the database type (e.g., Oracle, MySQL, MS SQL, etc…). The first step is to identify the type of database to hack into.

Determining the database type

A simple method to determine the database type is to intentionally create an error that varies depending on the database implementation. For instance, injecting the SQL statement using the string concatenation character is a common way of accomplishing this. Different database implementations use different characters to concatenate strings:

Let’s see how a hacker can take advantage of the above information:

Step 1: From the Web interface, we enter:

frank@’ + ‘smith.com

The input will be concatenated by the Web application to a pre-prepared string so that the resulting SQL statement will be something like:

SELECT * FROM Employees WHERE email = ‘frank’ + ‘@smith.com’;

The above query will run properly giving us the following results:

Step 2: We try now to run the same query, but using the Oracle concatenation character ||. From the Web interface, we enter:

frank@’ || ‘smith.com

The input will be concatenated by the Web application to a pre-prepared string so that the resulting SQL statement will be something like:

SELECT * FROM Employees WHERE email = ‘frank’ ||

‘@smith.com’;

The query will generate the following error message due to the invalid use of the Oracle concatenation character ||:

The details of the error message such as the System.Data.Sql- Client.SqlException reveal the database type name, that is, SQL Server. In fact, an SqlException is a type of exception used by the .NET framework that is generated whenever a warning or error is returned by an SQL Server database.

By performing such tests, we can identify the database type in a relatively short time.

Interacting with the operating system and the file

system

After information gathering, it is now time to exploit the vulnerabilities of the Web application at a deeper level. All commercial databases implement local file system access to export and import files to/from a database. Additionally, several Microsoft SQL database-stored procedures allow direct interactions with the server’s operating system. So, if we identify a way to manipulate these objects and the Web application user profile is granted the privileges to interact with them, we can read and write files, create users, and run programs/scripts.

We are going to demonstrate this attack, using an extended stored procedure available in Microsoft SQL Servers: xp_cmdshell. By embedding a call to this stored procedure into an SQL statement, we can cause data leakage. Let’s see how.

Step 1: From the Web interface, we enter the following code:

‘ exec master..xp_cmdshell ‘dir c: >C:\Inetpub\wwwroot\dir_list.txt’ –

The first ‘ is required because the prepared SQL statement is expecting an email address, that is a string. Therefore the ‘ character will end the expected string so that we can enter the malicious command:

exec master..xp_cmshell ‘dir c: > C:\Inetpub\wwwroot\dir_list.txt’

The command above will copy the output of the command dir C: (list of all files and directories on the C drive) into the folder C:\Inetpub\wwwroot\dir_list.txt which is the default location of an IIS Web server. We choose to try with IIS because from the previous example we identified that the Web application is built with .NET technology. Therefore it is highly likely that the Web server is IIS even though Apache can support .NET.

Ultimately, the — characters will comment everything that follows eliminating eventual additional parts of the query statement that may cause a syntax error.

Step 2: Since files residing within the IIS wwwroot directory can be accessed via browser, we can enter the following URL in the address bar to read the file we have just created:

http://www.targetwebsite.com/dir_list.txt

The exposure to SQL injections can be reduced by enforcing (1) input validation and (2) access control of the Web application user account. Input validation should ensure that “dangerous” characters typically used in SQL statements such as ;,=,”,’ are filtered out of the input provided by the user. The input validation should also consider the various encodings such as ASCII, base64, etc., that an attacker may use to bypass input validation. Therefore, a good approach would be to first convert the input into the standard encoding used by the Web application and then applying filtering rules to it.

Implementing access control of the Web application user account refers to ensuring the Web application account has access only to the resources necessary for the application to run. Access to store procedures, triggers, and any other database object that may allow access to the file system and the command line should be denied unless strictly necessary. In such situations, the permissions on the file system must be restricted as much as possible.

Cross Site Scripting (XSS)

Cross Site Scripting (XSS) is an attack that uses a slightly different approach from the other methods we have seen so far. It targets the Web application users rather than the application itself. XSS involves tricking legitimate users into executing malicious code unintentionally. XSS attacks thrive on the concept of exploitation of common Web application vulnerabilities such as insufficient input validation combined with social engineering (e.g., phishing) techniques. The commonly used programming languages for XSS attacks include JavaScript, ActiveX, and Livescript among others.

Universal XSS Attack

Universal XSS attacks take advantage of the features of the Document Object Model (DOM). DOM is a technology that allows programs and scripts to dynamically access and update documents including Web pages, PDF files, etc. The following attack scenario is just one of the many that a hacker could use:

Step 1: The hacker sends an email to his victims enticing them to read his article (my_article.pdf). However, the link also contains a malicious script:

Dear Customer,

We thought this article may be of interest for you and your business. To read the article, click on the following link: http://www.mywebsite.com/my_article.pdf#a=javascript: alert(‘XSS Attack!’);

Regards,

Customer Service

Step 2: When the victim clicks on the link, the Web browser (e.g., Internet Explorer, Firefox, etc.) will send the request for the PDF article to the server. The browser, however, will not send the portion of the link that follows the # sign. Then, Acrobat Reader will be launched to open the PDF file. At this point the entire URL will be passed to Acrobat Reader, along with the javascript, and will lead to the execution of the javascript code alert(‘XSS Attack!’):

In the above example, a harmless script displaying “XSS Attack!” on a pop-up window is executed. However, this type of attacks allows the execution of very dangerous code such as worms and viruses.

Cross Site Request Forgery (XSRF)

Although Cross Site Request Forgery (XSRF) sounds very similar to Cross Site Scripting (XSS), it uses a completely different approach. In a XSS attack, the “trusted” party is the server (or what the user believes to be the server) and the user’s browser executes the code coming from the trusted source. In a XSRF attack, a legitimate user of a website is involuntarily

directed to make a request to the server, which executes the request without verifying whether it was the actual user’s intent. A XSRF attack can be carried on as described below:

Step 1: The hacker controls a server (www.Hacking.com) where he has posted a link containing malicious code. The scope of the code is transferring money from the checking account of the victim to the hacker’s account.

Step 2: The victim logs into the e-banking system of his bank and performs his routine operations. The e-banking system assigns a session ID to the victim.

Step 3: The victim visits www.Hacking.com (e.g. by clicking on a link or through spam) which displays regular content as well as the link containing the malicious code. The user then clicks on that link.

Step 4: The malicious code directs the user’s browser to the e-banking system of the bank. The e-banking system authenticates the user’s browser with the valid session ID that was previously assigned to the user. The malicious code is executed and the hacker happily goes ahead and transfers the money from the victim’s checking account.

Although the example above sounds pretty neat, Cross Site Request Forgery is actually quite difficult to perform. The following requirements must be met for the attack to succeed:

1. The user has already authenticated into the e-banking system and the session token is still active.
2. The e-banking system allows actions to be performed without the need for re-authenticating the user using, for example, session tokens.
3. The hacker must know how to interact with the e-banking system and must know some intimate details such as knowing what function to call and which parameters to use.
4. The hacker also needs to fool the valid user and entice him into clicking on the link containing the malicious code.

Controls to prevent XSS and XSRF mainly entail strengthening input validation and educating users on phishing and other social engineering attacks. Input validation should focus on extrapolating potential XSS code. Therefore, JavaScript, ActiveX, and Livescript must be filtered out from the user input. Educating users on recognizing phishing attacks can be fostered by sending periodic informational emails on how those attacks may take place and how to recognize them. A service such as hotline for the clients to report phishing attacks can also be a valid tool to promote security awareness.

Conclusion

As with the old tale, Pandora could save only Hope in the box. There is hope with Web application security, too, despite the fact that Web applications are typically built with functionally in mind rather than security. Security professionals need to emphasize the importance of including security from the earliest stage of the Web application development life cycle in order to ensure that fundamental controls are not overlooked. As part of quality assurance, testing of session management, XSS, and SQL injection vulnerabilities should be performed prior to deploying the application to production. Periodic code reviews by an external specialized entity or an internal department, independent from development should be conducted in order to periodically re-assess the overall security of the Web application.

Furthermore, secure coding is another component as it can prevent many of the vulnerabilities described in this article. Programmers should be aware of the hacking techniques and trained in how the exposures to those threats can be reduced or eliminated in the application code.