The History of Web Application Security Risks

Report as inappropriate Your report has been received

Shared by: ijcsiseditor

Stats

views:: 217
posted:: 7/5/2011
language:: English
pages:: 8

Public Domain

/ 8 Download or Print

Document Sample

(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 9, No. 6, June 2011
,

The History of Web Application Security Risks
Fahad Alanazi Mohamed Sarrab
Software Technology Research Laboratory Software Technology Research Laboratory
De Montfort University De Montfort University
Leicester, LE1 9BH UK Leicester, LE1 9BH UK
P0800238x@mydmu.ac.uk msarrab@dmu.ac.uk

Abstract—this article refers generally to current web application employed to protect them.This paper will identify and discuss
risks that are causing public concern, and piquing the interest of ten web applications’ vulnerabilities, which constitute a threat
many scientists and organizations, as a result of an increase in to web applications’ security; assessing information provided
attacks. The primary concern of many governments, by researchers and OWASP regarding risk assessment and
organizations and companies is data loss and theft. Thus, these protection.
organizations are seeking to insure their web applications against
vulnerabilities. Revealing that awareness of the vulnerabilities of
II. INJECTION FLAWS
web applications leads to recognition of the need for
improvements. The three main facets of web security are: In 2007 OWASP [30] mentioned numerous Injection flaws
confidentiality, integrity and safety of content, and continuity. including: SQL, LDAP, XPath, XSLT, HTML, XML and OS;
This paper identifies and discusses ten web application with SQL being the most common of such injection types. In
vulnerabilities, detailing the opinions of researchers and OWASP 2004 OWASP [29] cited the main cause of vulnerability in
regarding risk assessment and protection. web applications to be there use of features of the operating
system and external programs to implement functions. This
enables attackers to exploit previous information from an
I. INTRODUCTION HTTP request, to inject malicious code as the web application
passes information through.
The Internet is a fascinating and multi-faceted technology,
opening a window on the world by allowing people across the The attack occurs when data is sent to the interpreter after the
globe to access information simply and quickly; allowing them user has initiated a command or query. The attacker exploits
to broadcast their ideas and culture, communicate and access this situation with the injection of malicious code alongside
research data from anywhere. It is now even seen as a form of the command or query, which enables full access to the system
e-government; based on its achievements in the last four years bypassing any protection and calling for data from operating
and the acquisition of 300 million users. systems and databases.OWASP in 2010 [31] described this
type of attack, as the attacker sending simple text to exploit the
However, the Internet lacks geographic borders, or national
syntax that targets the interpreter. Almost all data sources use
controls and this has led to concerns about the security of
an injection vector’ which includes internal sources. This flaw
conducting business online. Indeed; there are those who
is typically found in SQL queries, LDAP queries and OS
expend considerable effort in seeking to penetrate and steal
commands [21].
important information from websites, justifying apprehension
amongst the owners of this information and electronic service Recommendations
providers. Therefore, companies are doing their utmost to
maintain the confidentiality, privacy and accuracy of • Avoid using interpreters if possible.
information they hold (integrity); systems can now be
protected in a number of ways and some of the programs that • Input validation.
have helped in intrusion detection and reducing viruses have
somewhat eased the trepidation of network users. • Avoid detailed error messages that may be useful to
an attacker.
Recently attackers have turned their focus to web applications
which allow surfing, shopping, communication with • Reject all script injection (Gregory (2009).
companies in other countries, etc. This is because they rely on
databases to facilitate information exchange and the SQL Injection
distribution of information. These applications have an
increasing number of users, increasing their attractiveness to SQL injection is common among injection flaws, and yet
attackers, despite the numerous programmers and developers applications those are vulnerable to itare used in our daily

40 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 9, No. 6, June 2011

lives, relying on their safety; e.g. for making bookings and III. Cross Site Script (XSS)
paying bills. As the number of such applications increases, so
does the sophistication of the attacks that target them. The Cross site scripting is another intrusion method that
hackers use many methods to create defects in web manipulates the web browser to display malign code, which
applications; of these SQL injection is one of the easiest and then initiates in the user’s session. This can be done in a
most dangerous, potentially damaging the whole system. number of ways typically in Hypertext Markup Language
[HTML] [15]. Cross site scripting can be used in a number of
SQL injection is an attack in which SQL code is inserted or ways from theft of a cookie to taking over an entire session.
appended into application user input parameters that are later This is referred to as an intruder guided attack [18]. Insertion
passed to a back-end SQL server for parsing and execution of a script into a field can be an efficient attack but
[8]. SQL injection is a serious threat to any site or application circumventing the filter can be a problem. Cross site scripting
that contains a database; by injecting, and executing, the SQL uses an array of methods for abuse and intrusion [15].
code with basic code, attackers can gain unauthorized access
to private databases containing important and secure According to Ciampa[11] a Cross Site Script (XSS) attack is
information, thus compromising the integrity of sensitive data characterized by the use of special engineering; allowing the
by allowing for alteration or deletion [2]. SQL injection attacker, through the use of JavaScript language, to extract
attacks affect authentication processes impinging on the important information from the victim before utilizing it.
verification of user identity and allowing attackers to connect Lopez and Hammerli [24] argue that XSS is targeted on the
to the system without the password by using the query web application’s site and uses either stored XSS or reflected
language injection. XSS. The hackers attempt to attack users’ browsers and take
control with malicious script. When an attack is successful, the
Preventing SQL injection attacker can access important resources in the web application;
i.e. Cookies.
• String input must use two single quotation marks
rather than a single quotation mark. If there is single According to Belapurkar et al [5] these attacks rely on users to
quotation mark this should be replaced by two single input information and this means attackers can inject
quotation marks [10]. dangerous code whilst inputting data to gain access to the site.
The XSS often occur when the web application requires input
• Verification occurs from a single quotation mark in via a Username and Password page, as attackers can benefit
the inputs field, so if there is a single quotation it from this by tricking the user. In addition, any script entered
should be remove. in/form fields or in an URL is likely to pose a risk to the site
of this type of attack. XSS depends on injecting client-side
• Verification and removal of TSQL comments such as script, leading to account theft and changes to the content on a
– and /**/ because these comments might damage the page. XSS occurs when the web application fails to escape
data. user-submitted content properly before rendering it into
HTML [19].
• Detection and verification of TSQL keywords such as
SELECT, which might be used to query specific OWASP cited the ability of attackers to use XSS to send
elements. malicious code or script to an unsuspecting user, affecting
sensitive and important information that the browser has
• Ensure clients and server input. maintained as well as cookies and session tokens. The
malicious script can rewrite and rephrase the contents of the
• Use of elaborate SQL constructs that might cause HTML page because the browser does not know the origin of
errors and impede the execution of injected code. the script, or whether it can be trusted.OWASP divided this
type of attack into two categories:
• Verification from system records to limit the number
of users that do not have/do have an account in the • Stored: This attack is occurs through injection of
system to detect any unauthorized access to the malicious code or script into the target server and is stored
system by comparing these numbers. permanently in messages, comment forums or databases
etc. If/when the user requests information, the stored
• Use a secure policy for the system; by determining malicious script information is transferred to the server.
permissions, for example limiting some permission to
only reading and writing [16]. • Reflected: This type of attack is the most common type
and is reflected off the web server as in an error message.
This type of attack tricks the user when they click on links
where malicious script or code has been entered.

41 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 9, No. 6, June 2011

OWASP highlights the dangers of disclosure. When attackers • Use XSS filter to detect any malicious code [23].
hijack user’s sessions, full control is gained and the attacker
can access end user files. The attacker can also redirect the • Avoid special characters in input box such as <>, ―
user to pages or other sites and can modify presentation of ―, % , ; ) because these characters can help the
content by installing Trojan programs. Therefore, OWASP attacker to acquire sensitive data.
recommend verification from inputs and filtering to scripts
because most XSS attacks occur in JavaScript.XSS attack is • Limit the data that might be a part of scripting attack
dangerous for applications and servers due to the fact that [17].
most of these display simple web pages that contain errors
such as 500 “internal server error”. These may include IV. Buffer Overflow
information which enables attackers to corrupt the server and
the user’s browser by reflected attack. Buffer Overflow is an attack that occurs when web
applications have no control over input that might contain
In 2007, OWASP [30] referenced cross site script as a subset commands, encoding or improper formats. The attacker uses
of HTML injection. In this type of attack the victim‘s browser buffer overflow by inputting and overrunning the memory
is exploited by the attacker through executed script by user space which is used by the operating system [6]. Dubrawsky
sessions. All malicious scripts are related to JavaScript, but [12] argued that buffer overflow happens when the attacker
any scripting language supported by the victims’ browser may inputs additional information into the buffer that is (a holding
be vulnerable to this type of attack. OWASP described all the area for data) that cannot handle. Buffer overflow attack relies
associated web applications that are vulnerable to three types on programming language work that includes C and C++.
of XSS attack:
The buffer overflow occurs when the memory size exceeds the
• Reflected XSS: Easiest for exploiting the page. allocation for a buffer as a result failure to limit the inputted
information. Furthermore, it occurs when the web applications
• Stored XSS: The most dangerous is that it can take hostile use low-level programming languagesbecause these languages
data, store it within a file or database then at a later time do not perform automated bounds checking.
display the data for the user without a filter to detect input
Buffer overflow can happen if data is not checked for the
to the website.
length of value when copying it into the buffer from another
source, i.e. a Network socket [7]. This agrees with supports
• DOM based XSS: The JavaScript and variables are being
Wells’ [35] argument that storage flaws affects web
manipulated rather than HTML elements.
application security. According to Wells security measures
OWASP did not concentrate on these three areas, as in must be employed which include data encryption because web
addition there is a possibility of risky and unpredictable applications could contain sensitive information.
browser behaviors which may lead to attack. XSS may affect
Buffer overflows are in essence a technique used when data is
any components that the browser uses.
written into a fixed sized memory block resulting in memory
JavaScript allows for attack due to its strengths as a around the destination buffer becoming jammed and over
programming language which allows manipulation of the capacity. This would give the intruder access to parts of the
rendered page by adding new elements, internal DOM, processing memory allowing for the entry of malign code [13].
changing or deleting the page. Additionally, this type of attack This involves writing data to places in the memory stack that
permits use of XmIHttpRequest because attackers can contain information about the operating system, if this data is
circumvent the browser and forward the victim‘s data to accessed and overwritten then this usually results in a machine
aggressive sites, then create malicious codes to force open the crashing and the system resetting; the intruder can also make
browser for a long period of time. the process memory point to his code, which could result in
passwords being accessed or new accounts being created [9].
Recommendations The best way to overcome this kind of attack is to completely
avoid using a memory management system [13].
• Encode sensitive data.
OWASP [29] referred to web application components being
• Validate input data for length. improperly validated in some languages, leading to buffer
overflow attacks to access the system. This type of attack is
• To detect XSS in input donot use blacklist. difficult to detect and eradicate when discovered. Buffer
overflow can be found in the web application or‚ both the web
• Before using any untrusted data HTML tags should server or application server products that serve the static and
be removed [14]. dynamic aspects of the site. It can be found in custom web
application code but detection buffer overflow flaws are less

42 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 9, No. 6, June 2011

likely in custom web applications. If a custom application is where mistakes have commonly been made; unencrypted
discovered, the ability of the attacker is reduced, because ‚the critical data; insecure storage of keys, certificates, and
source code and detailed error messages for the application are passwords; improper storage of secrets in memory; poor
normally not available to the attacker. randomness selections; poor choice of algorithms; attempting
to invent new encryption algorithms; failure to include support
To determine if the server products are vulnerable there should for encryption key changes and other required maintenance
be a review of all code that accepts input from users via the procedures. Therefore, all websites which use encryption to
HTTP request to ensure that it can properly handle arbitrarily protect sensitive and important information in storage and
large input and ensure that it provides appropriate size transit are vulnerable to these kinds of attacks.
checking on all such inputs.
Detection of these flaws takes place in the following ways:
Buffer overflow was not mentioned in OWASP [30] or [31] Examine tokens, session IDs, cookies and other credentials to
because it was detected by either an; Intrusion Detection see if they are obviously not random. As a means of protection
System or IDS software, hardware or a combination of from this type of attack OWASP recommended a preference
both.There are two types of IDS: for re-entering data and not storage. OWASP also proposed,
where a need to use encryption exists, utilizing a library that is
• Network intrusion detection system: This can capture data exposed to public scrutiny and make sure that there are no
packets travelling on the network. open vulnerabilities [26, 29].
• Host-based intrusion detection systems: These can look
into the system and application log files to detect any In 2007 OWASP [30] cited failure to encrypt sensitive
intruder activity. information in web applications to be the result of poorly
designed cryptography. There are many associated
Recommendations cryptographic flaws that use inappropriate or strong ciphers,
which may lead to the discovery of sensitive data. As a result
• Do not use C and C++ programming language when OWASP mentioned that all web applications are
building a web application [32]. vulnerable.These were the most common problems in 2007.
Not encrypting sensitive data using home grown algorithms;
• Limit input data to prevent long input strings that insecure use of strong algorithms; continued use of known
might include malicious code [17]. weak algorithms (MD5, SHA-1, RC3, RC4…etc.); hard
coding keys; and, storing keys in unprotected stores.OWASP
V. Insecure Cryptographic Storage [31] again stated that the most common flaws relate to not
encrypting data, however, due to limited access precise flaws
Web applications sometimes use cryptographic functions in
are difficult to determine.
order to secure data. Unless these functions are coded
properly, this is not an easy thing to do.They can only offer a Recommendations
weak form of protection. Applications that do not offer a good
level of protection often use inappropriate ciphers. Thus, it is • Use only public algorithms.
advisable to ensure that everything is to be encoded is encoded
[21]. • Avoid using weak algorithms.
Recommendations: • Infrastructure credentials for web application such as
database credentials should be securely encrypted
• One should use only approved public algorithms. [21].
These include AES, RSA and public key.
• To protect insecure storage one must use proper
• Cryptography stores private keys with care. Try not encryption and access control for all data that is
to submit key over channels that are not guaranteed stored [17].
secure [21].
VI. Cross Site Request Forgery (CSRF)
In 2004 OWASP [29] highlighted this type of attack because
most web applications need to store sensitive and important Cross Site Request Forgery (CSRF) relies on XSS attack to
information such as passwords and account records in a file input dangerous code to the end user’s browser. This type of
system or database. Web applications developers thus resort to attack does not target the site that is implemented in these
encryption to protect this important information. However malicious codes but tricks the user to access other sites. CSRF
some developers have made mistakes whilst integrating affects web applications because it allows the attacker to
encryption into their web applications, they have also failed to change the victim’s stored information e.g. password
focus on other aspects of the site. There are several areas [13].Holovaty and Kaplan-Moss [19] show that CSRF occurs

43 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 9, No. 6, June 2011

when the attacker tricks the users by loading an URL from an open to this type of attack.In the 2004 and 2007 [29, 30]
authentication site to take advantage of their sites. According versions, this type of attack is based on sending forged
to Kategorileri [21], Broken Authentication and Session requests by submitting images, XSS flaws and other
management cause privacy violations. These flaws might lead techniques to trick the user. Thus the attacker is able to
to hijacking of administrative or user accounts, given the fact implement and change data whilst the victim is unable to carry
that there is no protection for credentials and session tokens out permitted authorised functions. OWASP remarked that all
throughout a web applications lifecycle. multistep transactions are unsafe because attackers can access
a series of requests by using JavaScript or multiple tags.
A cross site request forgery is an intrusion that is a request for
a page that appears to be sent from a trusted user. One To verify whether the application is vulnerable it should be
common example of this is when an image on a page is checked. Each link and form includes tokens that help the
embedded; this contains a link to a PHP script [4, 15, 33]. attackers to predict a particular action detail for each user.
Such intrusions can be used to gain entry to password Therefore OWASP have recommended that unique tokens be
protected parts of a website. If an intruder has convinced a inserted per user sessions and per request, thus disabling the
user to log onto a web application, then it can be used to attacker’s ability to predict URL, HTML requests and user
access to malign JavaScript. This can take over the user’s sessions details for a particular action [27].
session by releasing a false POST, using the user’s existing
session [22]. The conclusions drawn by OWASP in 2010 [31] indicated that
where the token is not unique, JavaScript or multiple tags help
Cross site request forgery intrusion can also be initiated by the attackers to exploit the web application; this helps the
sending a fake HTTP request from the user’s session. This can attackers to predict URL, HTML requests and user sessions
send information such as the user’s session cookie and other details and acquire sensitive data. In addition, JavaScript or
authorisation information. This is then passed onto a multiple tags that enable all multistep transactions should be
vulnerable web application which then thinks the intrusions considered unsafe.
are genuine requests for access [31].
Recommendations
In 2007 OWASP [30] mentioned that most web applications
are only based on automatically submitted credentials, such as • Every form should have a special token [22].
session cookies, basic authentication credentials, source IP
addresses, SSL certificates, or Windows domain credentials. • Variables are filled with a good data in order to
Therefore web applications are at risk. In addition cross site escape them [25].
request forgery has several other names: Session Riding and
One-Click Attacks. All web application frameworks in 2007 • Crypt ion session [1].
were vulnerable to cross site request forgery attacks.
• Use POST rather than GET [34].
CSRF usually takes place against a forum because it directs
the user to invoke some function, such as a logged page. • Do not click any link you do not recognise because it
Attackers can force the user, without their consent, to make might be used to send malicious requests to other
changes to their DSL router. The user‘s authorisation applications the user is logged into [13].
credentials are the reason these attacks work typically the
session cookie, so if the attacker could not supply credentials • Use browser tools, such as TG, to avoid and block
then the attack would fail. any change of user authentication by the website [20].

OWASP mentioned Cross Site Scripting (XSS) flaws which VII. Broken Authentication and Session Managements
are not required to work with Cross Site Request Forgery
(CSRF). Any web application with XSS flaws is retractable Another weakness that could make one‘s website vulnerable is
and vulnerable to CSRF attack because CSRF attack exploits improper protection of the certification apparatus, which is
XSS flaws for stealing any non-automatically submitted described as broken authentication. Broken session
credential. Defences should be built against CSRF attack by management relates to functions such as logout, timeout etc.
eliminating XSS vulnerabilities in applications because XSS Application functions that relate to session management, if not
flaws can circumnavigate most CSRF defences. implemented properly allow intruders to generate passwords
and keys, consequently assuming the identity of the user [17].
OWASP recommended verifying a web application so as to be
protected from this attack by generating and then requiring Session management restricts the gateway to applications that
some type of authorisation token that is not automatically use the web and information, and is authorised to shield and
submitted by the browser. OWASP [30] therefore contended ideally capable of protecting administrator privileges, such as
that applications failing to use unique tokens in requests were the username and password details.Organisations can demand

44 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 9, No. 6, June 2011

customised authentication, but this can lead to intruder VIII. Insecure Direct Object References
sessions being authorised, although this can be countermanded
by using built in security systems, such as SSL encryption These flaws resulted from developer error that exposes a direct
[28]. object reference such as a database, key or directory. A direct
object reference can occur when a developer leaves access to
In 2007, OWASP [30] identified flaws in the area of an object on the server such as a data file or database key. This
authentication and session management as related to the lack can be countered by means of an authorisation check; if not
of session token protection in the web application. These flaws performed this can enable intruders to alter references to these
can result in privacy violations through the hijacking of the files causing havoc to these systems [31]. When authorisation
user‘s administrative accounts. All authentication and session checks have been restricted or even stopped this vulnerability
management web application frameworks were found to be can appear. Where programmers usually use object references
vulnerable to this type of flaw at this time. directly in web interface, with no validation checks.
Weaknesses usually occur with ancillary authentication Insecure Direct Object Reference allows an attacker to access
functions such as logout, remember me and account update.In other objects in the web application without authorization by
2010, OWASP [31] stated that flaws within authentication and manipulating direct object references. Furthermore, this type
session management enable external attackers, and users who of attack occurs when there is exposure of reference, i.e. a
have accounts on the site, to steal information from other database record as well as form parameter or URL in an
accounts and hide their actions. Attackers impersonate users internal implementation object.
allowing access to exposed accounts, session IDs and
passwords by use of leaks in the session management OWASP [30] mentioned flaws that can occur when a direct
functions or authentication. object reference, such as a URL or form parameter and
database record is exposed by a developer. An attacker could
Recommendations access the object through manipulation of direct object
references, unless an access control check has been put in
• Do not accept from URL, or in requests, invalid or place without authorization. OWASP also mentioned that
new session identifiers. many applications expose internal object references to users,
enabling attackers through use of parameter tampering, to
• Limit or rid your code of custom cookies for violate access control policy by changing the references.
authentication or session management purposes.
In 2010, OWASP [31] mentioned flaws that occur when
• Use simple and more secure authentication developers expose references that take place within an internal
mechanisms. implementation object such as database key, directory and
files to the user. The attacker can therefore gain access to
• Use a strong password policy. unauthorized data through manipulation of references, due to
absence of protection or access control checks.The reason for
• Enable login process from an encrypted page. the continuation of these flaws in the web applications relates
to the fact that many applications which create web pages
• Make sure all client side cookies and server side utilize the actual name or key of an object and do not verify
session state are destroyed on logout. the user is authorized for the target object.
• Users should enter their old password when Recommendations
changing to a new password.
• Do not expose private object references to users.
• Use limited-time-only random numbers to reset
access and send a follow up e-mail as soon as the • Validate any private object references.
password has been reset. Beware self-registered
users changing their e-mail address - send a message • Verify authorization to all referenced objects.
to the previous e-mail address before enacting the
change [21]. • Verify from input that might include attack patterns
[21].
• Avoid authentication and session management
manipulation by the user to pass security control IX. Insecure Communications
[17].
OWASP highlighted the need to protect sensitive
communication because this will allow media sensitive data to
be exposed. Applications often fail to encrypt network traffic

45 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 9, No. 6, June 2011

that expose an authentication or session token. Therefore checks are performed before request to access a sensitive
encryption should be used for all authenticated connections function is granted.
and web pages that are accessible.All web application
frameworks mentioned by OWASP, are vulnerable to this Recommendations
flaw.
• Design of the application and architecture should
Such deficiencies enable the attacker to sniffer network traffic include access control matrix.
and gain access or capture sensitive and important
information, including transmitted credentials or • An effective access control mechanism to protect all
conversations, since every single request can contain a session URL and business functions.
token or authentication credential [30].Security breaches are
also possible when Insecure Communications occur when the • Make a penetration test for the application to ensure
web application does not have encryption for all authenticated application security.
connections and sensitive data [21].
• Make sure that administration is protected [21].
Recommendations
XI. Insufficient Transport Layer Protection
• Use SSL for all connections that are authenticated or
transmitting sensitive or value data. Insufficient Transport Layer Protection allows an attacker to
steal sensitive data or set access to the web application, due to
• Protect communications between infrastructure vulnerability exposing communication [3]. This arise using
elements by using protocol level encryption or expired, invalid or incorrect certificates which lead to
transport layer security [21]. applications failing to protect network traffic. These flaws are
very dangerous because the application does not use SSL/TLS
• Encrypt data. elsewhere during authentication so it might expose sensitive
data; i.e. session IDs of users, leading to account theft [31].
X. Failure to Restrict URL Access
Recommendations
According to Kategorileri [21], Failure to Restrict URL
Access occurs as result of a lack of access control checks. This • Use strong algorithms.
is because the web application usually protects an URL to
avoid the page presenting links to unauthorized users.Web • Use SSL for all sensitive pages in the applications.
access to internet addresses or URLs is checked before any
images or buttons on the page appear; this requires web • Use encryption technologies or SSL with backend
applications to perform checks every time these pages are and other connections.
viewed, or intruders will be able to gain access by forging
their URL addresses. Tools such as these cannot identify • Make sure the server certificate has not expired or
whether the page is accessible to the user, and therefore it is been revoked [4].
difficult to identify whether an issue exists with access [31]

Scanners are tools that can be used to find hidden URLs, but XII. CONCLUSIONS
they are unable to determine whether these functions or pages
are to be protected by any controls or restrictions. In order to
find these hidden pages they use a number of methods such as This paper presents and discusses ten web application
vulnerabilities, Injection Flaw, Cross-Site Scripting (XSS),
fuzzing directory and file names, directory lists, and also
trying to find backup and file folders. Buffer Overflow, Insecure Cryptographic Storage, Cross Site
Request Forgery (CSRF), Broken Authentication and Session
This form of attack is called forced browsing and contained Managements, Insecure Direct Object References, Insecure
guessing links and brute force techniques to find unprotected Communications, Failure to Restrict URL Access and
pages [30]. This can result in applications which allow access Insufficient Transport Layer Protection. Detailing the
for control code to develop into a complex model for researcher’s opinions and OWASP regarding risk assessment
developers and security specialists to understand. and protection. As aadopting the OWASP Top Ten is perhaps
the most effective first step towards changing the software
In 2010 OWASP [31] identified further serious threats to web development culture within organization into one that
applications being that anyone can send a request to a web produces secure code the paper provides some
application and therefore gain access to the network. Certain recommendation for adapting these ten web application
applications do not protect page requests correctly; i.e. no vulnerabilities.

46 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 9, No. 6, June 2011

REFERENCES http://serdarbuyuktemiz.blogspot.com/2008/09/owasp-top-
ten-2007-most-critical-web.html. [Accessed 29/08/2010].
[1]. Alameda, A. (2008). Foundation Rails 2. United States of [22]. Laurent, S.S. and Dumbill, E. (2007). Learning Rails.
America: Springer-Verlag New York, Inc, pp387-388. United States of America: O'Reilly Media, Inc.
[2]. Alqahtani, A. A. (2010) Security and Protection [23]. Lee, W. (2009). Windows 7: Up and Running: A Quick,
Information in Modern Web Application. Available from: Hands-On Introduction. United States of America: O'Reilly
http://coeia.edu.sa [Accessed 07/07/2010]. Media, Inc, p129.
[3]. Auger, R. (2010). Insufficient Transport Layer Protection. [24]. López, J. and Bernhard M. Hämmerli (2008). Critical
Available from: http://projects.webappsec.org/Insufficient- Information Infrastructures Security: Second International
Transport-Layer-Protection [Accessed 3/09/2010]. Workshop, CRITIS 2007, Benalmadena-Costa, Spain,
[4]. AUUGN (2005) The Conference for Unix, Linux and Open October 3-5, 2007. Germany: Springer-Verlag Berlin
Source Professionals. Available from: Heidelberg, p288.
http://books.google.co.uk/books?id=iJw5zAu7LncC&prints [25]. Makice, K. (2009). Twitter API: up and running. United
ec=frontcover&dq=AUUGN&hl=en&ei=HvKPTNfSE9CH States of America: O'Reilly Media, Inc, pp98-99.
4AbD3oyPDg&sa=X&oi=book_result&ct=result&resnum= [26]. McClure, S. and Scambray, J. and Kurtz, G. (2009).
1&ved=0CCoQ6AEwAA#v=onepage&q&f=false Hacking exposed 6: network security secrets & solutions.
[Accessed 25/08/2010]. United States of America: McGraw-Hill Companies, p592.
[5]. Belapurkar, A. et al. (2009). Distributed systems security: [27]. Mike Andrews, James A. Whittaker, J.A. (2006). How to
issues, processes, and solutions. United Kingdom: John break Web software: functional and security testing of Web
Wiley & Sons Ltd, pp105-106. applications and Web services, Volume 1. US: Pearson
[6]. Boyd, C. and Mao, W. (2003). Information security: 6th Education, Inc, pp66-67.
international conference, ISC 2003, Bristol, UK, October [28]. Overby, S. (2007) CIO. Available from:
1-3, 2003: proceedings, Volume 2851. Germany: Springer- http://books.google.co.uk/books?id=1woAAAAAMBAJ&p
Verlag Berlin Heidelberg New York, P367. g=PA68&dq=prevent+Broken+authentication+ans+session
[7]. Carey, M. et al. (2008). Nessus network auditing. United +management&hl=en&ei=_TB7TKCUF5GSswbomOSyD
States of America: Andrew Williams, p1. Q&sa=X&oi=book_result&ct=result&resnum=7&ved=0C
[8]. Clarke, J. (2009) SQL Injection Attacks and Defense. USA: FYEwBg#v=onepage&q&f=false [Accessed 28/08/2010].
Syngress Publishing, Inc. [29]. OWSAP (2004) The Ten Most Critical Web Application
[9]. Cole, E. (2002). Hackers beware. United Stated of Security Vulnerabilities. Available from:
America: New Riders Publishing, p248. http://ftp.ipv4.heanet.ie/
[10]. Cumming, A and Russell, G. (2007) SQL Hacks. USA: [30]. OWSAP (2007)The Ten Most Critical Web Application
O‘Reilly Media, Inc. Security Vulnerabilities. Available from:
[11]. Ciampa, M. (2008). Security+ Guide to Network Security http://www.owasp.org/images/e/e8/OWASP_Top_10_2007
Fundamentals. 3rd ed. Canada: Cengage Learning, p85. .pdf [Accessed 26/06/2010].
[12]. Dubrawsky, I. (2009). CompTIA Security+: Exam SYO [31]. OWSAP (2010) The Ten Most Critical Web Application
201, Study Guide and Prep Kit. United States of America: Security Vulnerabilities. Available from:
LanraColantoni, pp109-110. http://owasptop10.googlecode.com/files/OWASP%20Top
[13]. Dwivedi, H. and Clark, C. and Thiel, D. (2010). Mobile %2010%20-%202010.pdf [Accessed 26/06/2010].
Application Security. Unite States of America: The [32]. Peikari, C. And Chuvakin,A. (2004). Security warrior .
McGraw-Hill Companies, pp7-266. United States of America: O'Reilly Media, Inc, p167.
[14]. Flanagan, D. (2006). JavaScript: the definitive guide. 5th [33]. Powell, T.A. (2008). Ajax: the complete reference. unite
ed. United States of America: O'Reilly Media, Inc, pp267- States of America: The McGraw-Hill Companies, p322.
268. [34]. Shiflett, C. (2005). Essential PHP security. United States of
[15]. Ford, R. (2007). Infosecurity 2008 threat analysis. United America: O'Reilly Media, Inc, pp26-245.
States of America: Arnorette Pedersen. [35]. Wells, C. (2007). Securing Ajax applications. United States
[16]. Gama, J and Naughter, P. (2006) Super System: of America: O'Reilly Media, Inc, p51.
Turbocharge Database Performance. US: Rampant Teach
Press, Kittrell, NC, USA. AUTHORS PROFILE
[17]. Gregory, P. (2009). CISSP Guide to Security Essentials.
United States of America: Cengage Learning, p99. Fahad Alanazi is a PhD student in De Montfort University.
[18]. Grossman, J. and Hansen, R. (2007). XSS attacks: cross- Faculty of Technology.Software Technology Research
site scripting exploits and defense. United States of Laboratory (STRL). He received his B.Sc in computer science
from Tabouk University in Saudi Arabia and also received
America: Syngress Publishing, Inc.
MSc in Computer Security from De Montfort University. His
[19]. Holovaty, A. and Kaplan-Moss, J. (2009). The Definitive main research interests are Computer security and
Guide to Django: Web Development Done Right. United Computer forensic.
States of America: Springer-Verlag New York, Inc, p345.
[20]. Jakobsson, M. and Ramzan, Z. (2008). Crimeware: Dr. Mohamed Sarrab his Ph.D. degree in Computer Science
understanding new attacks and defenses. United Kingdom: from De Montfort University 2011. He received his B.Sc in
Symantec Press, p156. computer science from 7th April University Libya and also
[21]. Kategorileri, Y. (2008). OWASP Top Ten 2007 Most received M.Sc in Computer Science from VSB Technical
Critical Web Application Security Vulnerabilities University of Ostrava Czech Republic. His main research
interests are Computer security, Runtime Verification,
.Available from: Computer forensic.

47 http://sites.google.com/site/ijcsis/
ISSN 1947-5500