Web Application Related Security Issues Computer Science Essay

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

In this report, we describe the nature of the diverse web application related security issues, which were tested during the Internet Security module practical sessions. A number of simulators provided by Foundstone Professional Services, Hacme like casino, book store, shipping, bank, DotNet framework and MS SQL Server were tested. The result of these simulators was overwhelming that web applications undergo from number of vulnerabilities due to weak design of client-side and server-side applications. This report critically evaluates of these vulnerabilities with examples and countermeasures that can be taken to prevent these vulnerabilities.

Over the last few years, protecting the sensitive information against the attacker is one of the most important issues in web applications. Attackers are always in search of application weakness; once they are successful it will take no time in losing the victim's business essential information. It is often very difficult to identify clues left by the attackers as most of them are hidden or executed by server as valid commands.

Security professional are always need to be continually vigilant and fluent in different types of attack issues such as intrusion detection, incidence response, penetration testing and legal and audit compliance. The following section provides different sort technical details about different security issues.

2. Diverse Web Security Issues

Protecting web applications against latest emerging attacks are the most important business issues and companies are constantly struggling to protect their sensitive data. The following section provides information about general web application related security issues along with examples and general protection approaches.

2.1 XSRF (Cross-Site Request Forgery)

XSRF is a web application vulnerability that sends user sensitive information from currently authenticated websites to the malicious sites by using hyperlinks or other contents (Burns, 2007). The attacker can use functionality provided by websites such as email, message board, image tag and e-card to transfer user information from one website to another. For example, if a user is logged into a system (mybank.com) and the attacker sends an email containing the image link:

<img src=http://mybank.com/account/transferbalance.php?amount=1000&user=at_user />

Each time the user opens this email sends a request to mybank website and will transfer £1000 to user at_user (Spett, 2003). The transaction is performed as the logged in user, hence this sort of attack is fairly difficult to detect. If the web application allows certain function using POST or GET request then it opens door for the attackers (Auger, 2008).

The simple way to protect XSRF attack is to use user session token to each request and allocate time frame for token validation, clear cookies value each time or log off from one site before visiting another (Higgins, 2006).

2.2 Improper Session Handling

As web application is based on stateless HTTP protocol, it does not provide any way to authenticate the subsequent request came from the same user. To overcome this problem web applications implement different methods for maintaining sessions such as hidden form fields, cookies and URL arguments. Once users are logged on the system, session IDs are issued for accessing their sessions. This means session IDs act as identification tokens and also authentication (Kolsek 2002). If an attacker is able to obtain a valid session ID then he or she can directly enter that session without any suspicions.

For example, if an attacker logs into the server and has session ID 123, then he or she will send this session ID in a hyperlink http://www.example.com/login.jsp?sessionid=123 to the user. On clicking the link, it opens the login page in the user browser. Since the server has already created session for session ID 123, the request from the user will not create a new one. Finally, the user logs in server with username and password and access personal information. With the same session ID the attacker can access the user personal information through http://www.example/personal.jsp? sessionid=123. The attacker can browse user information until the user does not log out of the system.

The best protection approach for this kind of session mishandling is to generate a new session ID at each login and ignore previously generated one. Another way can be mapping session ID to the user IP address. This makes an attacker illegitimate user even he or she has valid session ID (Kolsek, 2002).

2.3 SQL Injection

SQL Injection is widely used technique for exploiting web applications that selects dynamic results based on user supplied data and text that are set for storage in a table. For instance: the following query will select all order details from Order table based on city supplied by the user.


$SQL = "select * from tblOrder where city = '" . $city . "'";

However, if the uses enters "Dundee'; delete from tblOrder -"in city then the above query will execute following select statement.

$SQL = "select * from tblOrder where city = 'Dundee'; delete from tblOrder-'

The ; (semicolon) represents the end of one query and begin of another and - (double hyphen) represents the rest of the line should be ignored (MSDN 2009). When the SQL server executes the query, firstly it will select all order where the city is Dundee then the server will delete all records from Order table.

Another form of exploiting is to use input data which will be stored in the database. For instance,


my feedback'); insert into tblOrder values (city, item, order)

values ('Perth', 'Book- SQL Injection',500); --

While entering the above feedback, the SQL server will initially insert feedback into a feedback table and then will insert a record in Order table (Hustad, 2006). Thus attackers can easily insert additional records to the company's database without any valid transactions.

As SQL server will execute any valid queries that it receives, it is very difficult to detect vulnerability by programmatically. Thus, we must validate all user supplied data in terms of type, length, format and range carefully before it is executing by SQL server (MSDN, 2009).

2.4 Blind SQL Injection

Web applications normally use SQL statements with user-supplied data to retrieve data or validate from a database. On success, users are allowed to enter in the system. An attacker can inject extra SQL parameters in data input to access on the system. A blind SQL injection is a type of SQL injection, where an attacker steals data by using a series of true and false operation in SQL Statements (CGISecurity, 2008). For example: a typical SQL Statement to validate user looks like

Select * from users where username = '<username>' and password = '<password>'

With malicious attacker input " 'or 1=1-" in username the query is changed into,

Select * from users where username=' or 1=1-and password='', which returns the first record from system (Smolen, 2006).

The best way to protect the blind SQL injection is to use stored procedures and prepared statements, where SQL statements are precompiled; making difficult for attackers to modify the original SQL queries (Spett, 2003).

2.5 Web Application Logical Vulnerability

Today most of website uses Ajax to update a small portion of an existing webpage rather than reloading the entire page. Using XMLHttpRequest and JavaScript object, Ajax can easily download a small piece of data from the server to dynamically update the content of the client. Unlike the tradition applications, where the entire logical code was stored on the server, with Ajax this logic is now distributed across both the client and server (Agarwal, 2006). This can be used by the attacker to understand the functionality of the web application.

For example, a user who is already authenticated to an Ajax application has the login credentials stored in her browser cookie. The web application uses JavaScript code to execute the Ajax application, data received from the application can be easily sent to the attacker (CBR, 2007).

2.6 Error Message Generation

The attacker can lunch additional attacks when he or she knows more information about the system. Since identifying the vulnerabilities requires some system level information, the attacker can craft new techniques that will pass through the validation filters and expose additional information (CWE-209, 2010). For instance the attacker will try apostrophe character in search input and most of websites does not filter this character. On successful, it will return extra system level information which will be enough to launch attack. The return information could be name of the database, server type, method name, type of error and absolute path of the application. The attacker can use this information to lunch more deadly other attacks.

Fig: error message without any filter

The above figure displays additional information about name of database, generic error message and error line number.

To prevent this vulnerability, the detailed error message should be internally handled and only user level information should be displayed to the user. For example, in PHP configure the environment function (error_reporting(), display_errors()) to display a short message (CWE-209, 2010).

2.7 Authorization Backdoor

Application developers often leave certain programming codes for trouble shooting or remotely accessing or updating the application, which ultimately bypasses the security mechanisms. These codes are in hidden process and the server does not require executing explicitly. The techniques can be adding code in a configuration file, use of services and AOP (Aspect Oriented Programming). Often the latest framework uses configuration files to specify class names and search parameters (Prados, 2009). An extra code can be executed by specifying the search parameter.

For example, in Java EE configuration file <warpath>/WEB-INF/<param.wsdd>, the program file in WEB-INF location is executed automatically when the web service is started.

Thus, the attackers can use various techniques to detect this sort of configuration and try to execute own vulnerable code. Also, the attacker can also install to install malicious software on the user system and will send back sensitive information.

The prevention approach for backdoor authorization is to check all the codes that run in escalated privileges.

2.8 Weak Cryptography

In order to transfer sensitive data over Internet, many web applications use cryptographic algorithms to prevent it reading from attackers. The proper implementation of cryptography is extremely important as a small mistake can cause an entire crypto implementation useless (CWE-327, 2010). For example,

Cipher des = Cipher.getInstance("DES....");


Few year before the Data Encryption Standard (DES) was considered as a strong algorithm, but it has been replaced by the Advanced Encryption Standard (AED). Using non-standard algorithm endangers the whole application that an attacker can easily use a determined attack to break whatever data has been protected.

The protection approach is to protect the cryptographic keys. If possible, keys should be stored in hardware crypto devices or physically in secure place. Applications should record any changes made to the keys (OWASP, 2005). Always use well tested and currently use algorithms rather than developing our own.

3. Conclusion

Over the last few years, the growing new technology and framework made the web application more vulnerable and open new doors for the attackers. Security bodies are mainly concerned about firewalls, antivirus, patching and privacy policies. It needs to examine the attack methodologies, entry points of web attack and suggested preventive approaches for effective and complete website vulnerability management.

5. References

Anurag Agarwal, 2006, Ajax Secuirty - A reality check [Online], Available from: http://searchsoftwarequality.techtarget.com/tip/0,289483,sid92_gci1219207,00.html, Accessed: 08 April 2010

CBR, 2007, Web 2.0 is a vulnerable to attack, [Online], Available from: http://www. cbronline.com/news/web_20_is_vulnerable_to_attack, Accessed: 08 April 2009

CGIsecurity, 2008 Blind SQL Injection [Online], Available from: http://www.cgisecurity.com/questions/blindsql.shtml, Accessed: 07 April 2010

CWE-209, 2010, Information Exposure Through an Error Message, [Online] Available from: http://cwe.mitre.org/data/definitions/209.html, Accessed: 08 April 2010

Hustad Roman, 2006, Foundstone Hacme Books V2.0, Strategic Secure Software Training Application, [Online] Available from: http://www.foundstone.com/us/resources/whitepapers/ hacmebooks_userguide2.pdf, Accessed: 5 April 2010

Kelly Jackson Higgins, 2006, CSRF Vulnerability: A 'Sleeping Giant' [Online], Available from: http://www.darkreading.com/security/app-security/showArticle.jhtml?articleID=20880 4131 , accessed 07 April 2010-04-07

Kevin Spett, 2003, SPI Labs, Blind SQL Injection [Online], Available from: http://www.net-security.org/dl/articles/Blind_SQLInjection.pdf, accessed 07 April 2010

Mitja Kolsek, 2002, Session Fixation Vulnerability in Web-based Applications [Online], Available from: http://www.acros.si/papers/session_fixation.pdf, Accessed: 07 April 2009

MSDN, 2009, SQL Injection [Online], Available from: http://msdn.microsoft.com/en-us/library/ms161953.aspx, Accessed: 10 April 2010

OWASP, 2005, Guide to Building Secure Web Applicaitons and Web Services, Chapter 19: Cryptography [Online], Available from: http://searchsoftwarequality.techtarget.com/news /article/0,289142,sid92_gci1157341,00.html, Accessed 08 April 2010

Philippe Prados, 2009, Back door into Java EE Application servers [Online] Available from: http:// macaron.googlecode.com/files/en-macaron.pdf, Accessed: 09 April 2010

Robert Auger, 2008, The Cross-Site Request Forgery (CSRF/XSRF) FAQ [Online], Available from: http://www.cgisecurity.com/csrf-faq.html, Accessed 08 April 2009