,
The History of Web Application Security Risks
Fahad Alanazi
Software Technology Research Laboratory
De Montfort UniversityLeicester, LE1 9BH UK
P0800238x
@mydmu.ac.uk Mohamed SarrabSoftware Technology Research LaboratoryDe Montfort UniversityLeicester, LE1 9BH UK msarrab@dmu.ac.uk
Abstract
—
this article refers generally to current web applicationrisks that are causing public concern, and piquing the interest of many scientists and organizations, as a result of an increase inattacks. The primary concern of many governments,organizations and companies is data loss and theft. Thus, theseorganizations are seeking to insure their web applications againstvulnerabilities. Revealing that awareness of the vulnerabilities of web applications leads to recognition of the need forimprovements. The three main facets of web security are:confidentiality, integrity and safety of content, and continuity.This paper identifies and discusses ten web applicationvulnerabilities, detailing the opinions of researchers and OWASPregarding risk assessment and protection.
I.
INTRODUCTIONThe Internet is a fascinating and multi-faceted technology,opening a window on the world by allowing people across theglobe to access information simply and quickly; allowing themto broadcast their ideas and culture, communicate and accessresearch data from anywhere. It is now even seen as a form of e-government; based on its achievements in the last four yearsand the acquisition of 300 million users.However, the Internet lacks geographic borders, or nationalcontrols and this has led to concerns about the security of conducting business online. Indeed; there are those whoexpend considerable effort in seeking to penetrate and stealimportant information from websites, justifying apprehensionamongst the owners of this information and electronic service providers. Therefore, companies are doing their utmost tomaintain the confidentiality, privacy and accuracy of information they hold (integrity); systems can now be protected in a number of ways and some of the programs thathave helped in intrusion detection and reducing viruses havesomewhat eased the trepidation of network users.Recently attackers have turned their focus to web applicationswhich allow surfing, shopping, communication withcompanies in other countries, etc. This is because they rely ondatabases to facilitate information exchange and thedistribution of information. These applications have anincreasing number of users, increasing their attractiveness toattackers, despite the numerous programmers and developersemployed to protect them.This paper will identify and discussten web applications’ vulnerabilities, which constitute a threatto web applications’ security; assessing information provided by researchers and OWASP regarding risk assessment and protection.II.
INJECTION FLAWSIn 2007 OWASP [30] mentioned numerous Injection flawsincluding: SQL, LDAP, XPath, XSLT, HTML, XML and OS;with SQL being the most common of such injection types. In2004 OWASP [29] cited the main cause of vulnerability inweb applications to be there use of features of the operatingsystem and external programs to implement functions. Thisenables attackers to exploit previous information from anHTTP request, to inject malicious code as the web application passes information through.The attack occurs when data is sent to the interpreter after theuser has initiated a command or query. The attacker exploitsthis situation with the injection of malicious code alongsidethe command or query, which enables full access to the system bypassing any protection and calling for data from operatingsystems and databases.OWASP in 2010 [31] described thistype of attack, as the attacker sending simple text to exploit thesyntax that targets the interpreter. Almost all data sources usean injection vector’ which includes internal sources. This flawis typically found in SQL queries, LDAP queries and OScommands [21].
Recommendations
•
Avoid using interpreters if possible.
•
Input validation.
•
Avoid detailed error messages that may be useful toan attacker.
•
Reject all script injection (Gregory (2009).
SQL Injection
SQL injection is common among injection flaws, and yetapplications those are vulnerable to itare used in our daily
(IJCSIS) International Journal of Computer Science and Information Security,Vol. 9, No. 6, June 201140http://sites.google.com/site/ijcsis/ISSN 1947-5500
lives, relying on their safety; e.g. for making bookings and paying bills. As the number of such applications increases, sodoes the sophistication of the attacks that target them. Thehackers use many methods to create defects in webapplications; of these SQL injection is one of the easiest andmost dangerous, potentially damaging the whole system.SQL injection is an attack in which SQL code is inserted or appended into application user input parameters that are later passed to a back-end SQL server for parsing and execution[8]. SQL injection is a serious threat to any site or applicationthat contains a database; by injecting, and executing, the SQLcode with basic code, attackers can gain unauthorized accessto private databases containing important and secureinformation, thus compromising the integrity of sensitive data by allowing for alteration or deletion [2]. SQL injectionattacks affect authentication processes impinging on theverification of user identity and allowing attackers to connectto the system without the password by using the querylanguage injection.
Preventing SQL injection
•
String input must use two single quotation marksrather than a single quotation mark. If there is singlequotation mark this should be replaced by two singlequotation marks [10].
•
Verification occurs from a single quotation mark inthe inputs field, so if there is a single quotation itshould be remove.
•
Verification and removal of TSQL comments such as – and /**/ because these comments might damage thedata.
•
Detection and verification of TSQL keywords such asSELECT, which might be used to query specificelements.
•
Ensure clients and server input.
•
Use of elaborate SQL constructs that might causeerrors and impede the execution of injected code.
•
Verification from system records to limit the number of users that do not have/do have an account in thesystem to detect any unauthorized access to thesystem by comparing these numbers.
•
Use a secure policy for the system; by determining permissions, for example limiting some permission toonly reading and writing [16].III.
Cross Site Script (XSS)Cross site scripting is another intrusion method thatmanipulates the web browser to display malign code, whichthen initiates in the user’s session. This can be done in anumber of ways typically in Hypertext Markup Language[HTML] [15]. Cross site scripting can be used in a number of ways from theft of a cookie to taking over an entire session.This is referred to as an intruder guided attack [18]. Insertionof a script into a field can be an efficient attack butcircumventing the filter can be a problem. Cross site scriptinguses an array of methods for abuse and intrusion [15].According to Ciampa[11] a Cross Site Script (XSS) attack ischaracterized by the use of special engineering; allowing theattacker, through the use of JavaScript language, to extractimportant information from the victim before utilizing it.Lopez and Hammerli [24] argue that XSS is targeted on theweb application’s site and uses either stored XSS or reflectedXSS. The hackers attempt to attack users’ browsers and takecontrol with malicious script. When an attack is successful, theattacker can access important resources in the web application;i.e. Cookies.According to Belapurkar et al [5] these attacks rely on users toinput information and this means attackers can injectdangerous code whilst inputting data to gain access to the site.The XSS often occur when the web application requires inputvia a Username and Password page, as attackers can benefitfrom this by tricking the user. In addition, any script enteredin/form fields or in an URL is likely to pose a risk to the siteof this type of attack. XSS depends on injecting client-sidescript, leading to account theft and changes to the content on a page. XSS occurs when the web application fails to escapeuser-submitted content properly before rendering it intoHTML [19].OWASP cited the ability of attackers to use XSS to sendmalicious code or script to an unsuspecting user, affectingsensitive and important information that the browser hasmaintained as well as cookies and session tokens. Themalicious script can rewrite and rephrase the contents of theHTML page because the browser does not know the origin of the script, or whether it can be trusted.OWASP divided thistype of attack into two categories:
•
Stored: This attack is occurs through injection of malicious code or script into the target server and is stored permanently in messages, comment forums or databasesetc. If/when the user requests information, the storedmalicious script information is transferred to the server.
•
Reflected: This type of attack is the most common typeand is reflected off the web server as in an error message.This type of attack tricks the user when they click on linkswhere malicious script or code has been entered.
(IJCSIS) International Journal of Computer Science and Information Security,Vol. 9, No. 6, June 201141http://sites.google.com/site/ijcsis/ISSN 1947-5500
OWASP highlights the dangers of disclosure. When attackershijack user’s sessions, full control is gained and the attacker can access end user files. The attacker can also redirect theuser to pages or other sites and can modify presentation of content by installing Trojan programs. Therefore, OWASPrecommend verification from inputs and filtering to scripts because most XSS attacks occur in JavaScript.XSS attack isdangerous for applications and servers due to the fact thatmost of these display simple web pages that contain errorssuch as 500 “internal server error”. These may includeinformation which enables attackers to corrupt the server andthe user’s browser by reflected attack.In 2007, OWASP [30] referenced cross site script as a subsetof HTML injection. In this type of attack the victim‘s browser is exploited by the attacker through executed script by user sessions. All malicious scripts are related to JavaScript, butany scripting language supported by the victims’ browser may be vulnerable to this type of attack. OWASP described all theassociated web applications that are vulnerable to three typesof XSS attack:
•
Reflected XSS: Easiest for exploiting the page.
•
Stored XSS: The most dangerous is that it can take hostiledata, store it within a file or database then at a later timedisplay the data for the user without a filter to detect inputto the website.
•
DOM based XSS: The JavaScript and variables are beingmanipulated rather than HTML elements.OWASP did not concentrate on these three areas, as inaddition there is a possibility of risky and unpredictable browser behaviors which may lead to attack. XSS may affectany components that the browser uses.JavaScript allows for attack due to its strengths as a programming language which allows manipulation of therendered page by adding new elements, internal DOM,changing or deleting the page. Additionally, this type of attack permits use of XmIHttpRequest because attackers cancircumvent the browser and forward the victim‘s data toaggressive sites, then create malicious codes to force open the browser for a long period of time.
Recommendations
•
Encode sensitive data.
•
Validate input data for length.
•
To detect XSS in input donot use blacklist.
•
Before using any untrusted data HTML tags should be removed [14].
•
Use XSS filter to detect any malicious code [23].
•
Avoid special characters in input box such as <>,
―
―
, % , ; ) because these characters can help theattacker to acquire sensitive data.
•
Limit the data that might be a part of scripting attack [17].IV.
Buffer OverflowBuffer Overflow is an attack that occurs when webapplications have no control over input that might containcommands, encoding or improper formats. The attacker uses buffer overflow by inputting and overrunning the memoryspace which is used by the operating system [6]. Dubrawsky[12] argued that buffer overflow happens when the attacker inputs additional information into the buffer that is (a holdingarea for data) that cannot handle. Buffer overflow attack relieson programming language work that includes C and C++.The buffer overflow occurs when the memory size exceeds theallocation for a buffer as a result failure to limit the inputtedinformation. Furthermore, it occurs when the web applicationsuse low-level programming languagesbecause these languagesdo not perform automated bounds checking.Buffer overflow can happen if data is not checked for thelength of value when copying it into the buffer from another source, i.e. a Network socket [7]. This agrees with supportsWells’ [35] argument that storage flaws affects webapplication security. According to Wells security measuresmust be employed which include data encryption because webapplications could contain sensitive information.Buffer overflows are in essence a technique used when data iswritten into a fixed sized memory block resulting in memoryaround the destination buffer becoming jammed and over capacity. This would give the intruder access to parts of the processing memory allowing for the entry of malign code [13].This involves writing data to places in the memory stack thatcontain information about the operating system, if this data isaccessed and overwritten then this usually results in a machinecrashing and the system resetting; the intruder can also makethe process memory point to his code, which could result in passwords being accessed or new accounts being created [9].The best way to overcome this kind of attack is to completelyavoid using a memory management system [13].OWASP [29] referred to web application components beingimproperly validated in some languages, leading to buffer overflow attacks to access the system. This type of attack isdifficult to detect and eradicate when discovered. Buffer overflow can be found in the web application or‚ both the webserver or application server products that serve the static anddynamic aspects of the site. It can be found in custom webapplication code but detection buffer overflow flaws are less
(IJCSIS) International Journal of Computer Science and Information Security,Vol. 9, No. 6, June 201142http://sites.google.com/site/ijcsis/ISSN 1947-5500
Search History:
Result 00 of 00
00 results for result for
p.
The History of Web Application Security Risks
This article refers generally to current web application risks that are causing public concern, and piquing the interest of many scientists and organizations, as a result of an increase in attacks. The primary concern of many…
(More)
1.0K
Reads
0
Readcasts
0
Embed Views
Get Scribd Mobile
To get Scribd mobile enter your number and we'll send you a link to the Scribd app for iPhone & Android.We've sent a link to the Scribd app. If you didn't receive it, try again.
We'll never share your phone number.
More From This User
Notes
Load more
