Introduction’“”
why
In this paper, a critical discussion is given in order to provide a comprehensive view of the most frequent web application violations the Injection and authentication flaws based on OWASP (Open Web Application Security Project) 2010. For doing so, the discussion paper will consider injections and authentication flaws in three different sections.
In section 1, a further description regarding injections and authentication flaws is provided, including practical examples that enable user to follow this paper. Moreover, section 2 considers a critical discussion upon security defences against cross site scripting and SQL injections, being two of the major vulnerabilities of web applications. Possible improvements against cross site scripting and SQL injections are presented in section 3. This discussion paper concludes by providing a summary of author�s ideas in relation to injection and authentication flaws.
Section 1: Injection and Authentication flaws
Nowadays there is an increasing dependency on web applications, ranging from individuals to large organizations. The market of web applications is considered to be one of the most fast growing markets whereby personal web pages and blogs to social networks (i.e. facebook), online bank agencies and e-commerce applications are developed. The majority of articles emphasize that “almost everything is stored, available or traded on the web, making web applications a natural target for malicious minds”
Another aspect of injection and authentication flaws has been stated by Paul Sebastian in one of his articles. He believes that “websites security has been a persistent and major concern ever since the Internet became an essential part of many people�s lives.” He also considered that “injection of code into various parts of dynamic websites poses a dangerous, but also very interesting threat to security.”
Therefore, this discussion paper addresses that web applications are highly exposed to attacks and to inexperienced developers and administrators without the required experience in the area of security.
As Christian Heilman mentioned in his article, path traversal, cross-site scripting, and SQL injection are considered to be among the most serious vulnerabilities. Diagram 1 shows a classification of web vulnerabilities. He also believes that a web developer has to deal with such authentication flaws relating to PHP and HTML, CSS and JavaScript. In particular, someone that does not use PHP, he could still cause a lot of problems. Similarly if web developer does not touch code and simply design, he could be considered as a great asset in this area. Therefore it is very important that web developers take the necessary means so that security issues are understandable to the users and therefore make web a safe place to operate.
1.1 Cross-Site Scripting (XSS)
Academics in Italy described cross site scripting (XSS) “as the vulnerability of a Web application that is essentially caused by the failure of the application to check up on user input before returning it to the client's Web browser. ” They also considered that without an adequate validation, user input may include malicious code that may be sent to other clients and unexpectedly executed by their browsers, thus causing a security attack.
In practice for example, Sarah Brown is among thousands of twitter users who have been hit by malicious use of a security flaw in the redesigned twitter site. Several press articles state that the she has more than a million followers on twitter, unknowingly sent a link which contained malicious code that would redirect anyone who moved their mouse over it without click it to an adult content website.As Charles Arthur stated to his article, the exploit, using a method known as "cross-site scripting" (XSS), had been an embarrassment for Twitter, which launched its new-look website a week ago, including links to third-party sites for pictures and video.
1.2 SQL Injection
A significant vulnerability of injection and authentication flaws is what is known as SQL injection. This can be described in several ways and it is ranked at �the top in web application attack mechanisms used by hackers to steal data from organizations�. Moreover, academic studies support that �hackers' can take advantages due to flawed design, improper coding practices, improper validations of user input, configuration errors, or other weaknesses in the infrastructure�
SQL Injection can be further described by considering real life examples such as the decision taken by the management of Nokia, in the telecommunications industry. In particular, there was a recent announcement that the Company suffered a security breach which exposed personal information, including dates of birth and e-mail addresses, belonging to members of its development community. According to the statement, �the attacker used "SQL injection" to access the forum database at developer.nokia.com�. �The database table records includes members� e-mail addresses and, for fewer than 7 per cent who chose to include them in their public profile, either birth dates, homepage URL or usernames for AIM, ICQ, MSN, Skype or Yahoo!�.
Section 2: Defences against cross-scripting and SQL injection
The significant increase in depending on web applications caused vulnerabilities with cross scripting and SQL injection being the most important as mentioned above. On that basis, this paper also describes the defences that several academics and reviewers believe will help to minimise such security deficiencies.
2.1 Cross-Site Scripting (XSS)
There are a few guidelines that can be followed to help safeguard web applications against XSS attacks. Shar, Lwin Khin, Tan, and Hee Beng Kuan stated in their research that �most of xss attacks are based on malicious input is submitted to perform unintended actions on a HTML response page�.
2.1.1. Filtering all input
This discussion paper illustrates in Figure 1 how the form of a malicious input might appear in a browser. In such case it is recommended that the web developer must filter all input without fail and inspect all input in order to ensure that only valid data are allowed into the application. Instead of trying to predict what malicious data you want to reject, define your criteria for valid data, and force all input to abide by your guidelines. For example, if a user is supplying a last name, you might start by only allowing alphabetic characters and spaces, as these are safe.
After implementing much of the logic relating to filtering requests, I believe that concluded that it would be best to handle this in a separate application all together.
A defence against cross scripting that is also considered to be important is what the Open Web Application Security Project (OWASP) supports. The not-for-profit worldwide charitable organization focused on improving the security of application software and therefore it mentions that a web developer needs to take the following measures against XSS attacks:
2.1.2. Data Validation
In my opinion, OWASP defences are reasonable although I believe that XSS attacks can be mitigated in the short run, whereby different codes may secure internet environment, and not in the long term because there are always threats in the huge field of internet.
Moreover, I agree with of what is has been proposed by OWASP with respect to data validation because it is important that no bad input data can be inserted. On that basis, java script validation such as username and password fields can be used so as to achieve the validation of all input forms. An example of data validation is shown in Figure 2.
According to Martin D�rst at W3C organisation, validation of all headers is an important defence for XSS attacks and therefore the web developer needs to �make sure for the correct decoding of the document under assessment�. In such case, �an error message will be shown if information about the encoding was not found and there is a conflict of information, or even if decoding the document according to the information found is not possible�.
2.2 SQL Injection
This paper proposes defences with which an SQL injection can be safeguarded and therefore it should be consider prior the preparation of a code. Although it is widely known that there is not the perfect solution for each problem, the protection of a site against SQL injection could be involve the following defences:
2.2.1 Prevent database attack
A major defence is consider to be the mysql_real_escape_string() function that it escapes special characters in a string for use in an SQL statement. For example, the following characters are affected:
#box_1 {
position: static;
width: 200px;
height: 200px;
background: #ee3e64;
}
This function returns the escaped string on success, or FALSE on failure.
Academics research shows that �errors should not be displayed to the user, containing information about the database or actual source code�. This is because �error messages are useful to an attacker because they give additional information about the database that might not otherwise be available�. On that basis, I also believe that the website should show a general error message rather than indicating the exact code which can be used by the attacker (Tajpour, A., Masrom, M., Heydari, M.Z. and Ibrahim, S. - CASE Center, Univ. Technology in Malaysia). For example, stripslashes() function removes backslashes added by the addslashes() function and it overall helps in cleaning up data retrieved from a database or from an HTML form.
2.2.2 Set length limits on any form fields and avoid using real column names
SANS Institute research resulted to the fact that �if you have a login screen, generally there are two windows � one for the username and one for the password. This should limit to a realistic number�.
Therefore, it is recommended that the web developer �does not use the real column names as the field names as this just makes life easier for an attacker�.
2.2.3. Data validation at a minimum for content, length and format
In my opinion, it is important for the web developer to save time and in this respect perform data on the server side. In addition the format of the code should contain different data for several validations. According to Litchfield "all of this would 'go away' if the ASP coder properly sanitised user input before letting it anywhere near an SQL query."
Section 3: Conclusions and Reccomendations
Studies from SANS Institute indicate that an SQL injection attack is reduced by having proper stored procedures. It has been stated that �it is very important to use parameters at all times�. In my opinion this is a correct approach since this may be time consuming but it minimises possible threats. To quote Anley: �Essentially, if a parameterised query is run, and the user-supplied parameters are passed safely to the query, then SQL injection is typically impossible�
Unless a web application has a strong, centralized mechanism for validating all input from HTTP requests (and any other sources), vulnerabilities based on malicious input are very likely to exist. As to that, we must emphasize one and only thing: hackers constantly find new vulnerabilities to attack, so only one or an older validation rule may lose efficiency. We propose an automatic mechanism adjusting validation rules. The system is designed to protect web sites from attack and do not require modification of application source code