See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/261389106

A survey on web application vulnerabilities and countermeasures

Conference Paper · January 2011

CITATIONS READS
32 11,174

4 authors, including:

Atefeh Torkaman Marjan Bahrololum

Tarbiat Modares University Iran Telecommunication Research Center
12 PUBLICATIONS 82 CITATIONS 11 PUBLICATIONS 188 CITATIONS

SEE PROFILE SEE PROFILE

Mohammad Hesam Tadayon

Iran Telecommunication Research Center
38 PUBLICATIONS 465 CITATIONS

SEE PROFILE

All content following this page was uploaded by Atefeh Torkaman on 06 November 2016.

The user has requested enhancement of the downloaded file.

 A Survey on Web Application Vulnerabilities and Countermeasures

Hasty Atashzar Atefeh Torkaman Marjan Bahrololum Mohammad H. Tadayon

h_atashzar@vu.iust.ac.ir torkaman@itrc.ac.ir bahrololum@itrc.ac.ir tadayon@itrc.ac.ir
ICT Research Institute ICT Research Institute ICT Research Institute ICT Research Institute
(ITRC) (ITRC) (ITRC) (ITRC)

dangerous current Web application security flaws, along with

Abstract- Security vulnerabilities continue to infect web effective methods of dealing with those flaws [1].
applications, allowing attackers to access sensitive data and OWASP is an organization that provides unbiased and
exploiting legitimate web sites as a hosting ground for practical, cost-effective information about computer and
malware. Consequently, researchers have focused on various Internet applications. Project members include a variety of
approaches to detect and prevent critical classes of security security experts from around the world who share their
vulnerabilities in web applications, including anomaly-based knowledge of vulnerabilities, threats, attacks and
and misuse-based detection mechanisms, static and dynamic countermeasures. It is an Open community dedicated to
server-side and client-side web application security policy enabling organizations to develop, purchase, and maintain
enforcement. applications that can be trusted. OWASP contains:
This paper present a survey on web application security • Application security tools and standards
aspects includes critical vulnerabilities, hacking tools and also • Complete books on application security testing, secure
approaches to improve web application and websites security Code development and security code review
level. • Standard security controls and libraries
• Local chapters worldwide
Keywords; Web Application Security, Web Application • Cutting edge research
Vulnerabilities, Fundamental and Mitigating Solution • Extensive conferences worldwide
• Mailing lists
INTRODUCTION • And more

This paper mainly focuses on OWASP Top Ten risks

Various web sites provide a variety of services on the and its countermeasures released in 2010. The rest of the paper
Internet. According to “Communications Usage Trend is organized as follows. Section one presents the most critical
Survey”1, businesses grow increasingly dependent upon Web vulnerabilities of the web applications. Section 2 reviews the
applications and social interaction through the web sites is fundamental solutions against the mentioned vulnerabilities.
expected to keep growing. Most organizations equip their Web Web Application hacking tools and mitigating solutions is
sites with firewalls, Secure Sockets Layer (SSL) and network presented in section three, and finally section four reviews the
and host security devices. However the majority of attacks are paper and draws a conclusion.
on applications themselves and these technologies cannot
prevent them. According to IPA (Information-Technology
Promotion Agency), more than 75 Percent attack occurs to I. WEB APPLICATION VULNERABILITIES
Web Application [3]. A. Injection
There are various approaches to increase the web Injection flaws, such as SQL, OS, and LDAP injection,
applications security such as validation of input and output occur when untrusted data is sent to an interpreter as part of a
data, avoiding storing data that you do not need on the website command or query. The attacker‟s hostile data can trick the
and its database(s). interpreter into executing unintended commands or accessing
The Open Web Application Security Project (OWASP) unauthorized data [1-2, 4- 5].
provides the Top Ten project which is a list of the 10 most
B. Cross Site Scripting (XSS)
XSS flaws occur whenever an application takes
1
Communication Usage Trend Survey, Ministry of Internal untrusted data and sends it to a web browser without proper
Affairs and Communications (MIC) validation and escaping. XSS allows attackers to execute
http://www.soumu.go.jp script in the victim‟s browser which can hijack user sessions,

647
deface web sites, or redirect the user to malicious sites [1, 8- attackers can redirect victims to phishing or malware sites, or
9]. use forwards to access unauthorized pages [1].

C. Broken Authentication and Session Management II. HOW TO PROTECT YOUESELF

Application functions related to authentication and There are various mitigating solutions for Web
session management are often not implemented correctly, Application vulnerabilities. Figure 1 shows many points
allowing attackers to compromise passwords, keys, session within a system that might require protection [14]. The rest of
tokens, or exploit implementation flaws to assume other users‟ this section presets the fundamental solution against the
identities [1]. mentioned Web Application vulnerabilities.

D. Insecure Direct Object References

A direct object reference occurs when a developer
exposes a reference to an internal implementation object, such
as a file, directory, or database key. Without an access control
check or other protection, attackers can manipulate these
references to access unauthorized data [1].

E. Cross Site Request Forgery (CSRF)

A CSRF attack forces a logged-on victim‟s browser to
send a forged HTTP request, including the victim‟s session
cookie and any other authentication information, to a
vulnerable web application. This allows the attacker to force
the victim‟s browser to generate requests the vulnerable
application thinks are legitimate requests from the victim [1,
6-7].
Fig 1. Mitigating Solution against Web Application Vulnerabilities [15]

F. Security Misconfiguration
A. Injection
Security depends on having a secure configuration
The simplest way to protect against injection is to avoid
defined for the application, framework, web server,
accessing external interpreters wherever possible. For many
application server, and platform. All these settings should be
shell commands and some system calls, there are language
defined, implemented, and maintained as many are not
specific libraries that perform the same functions. Using such
shipped with secure defaults [1].
libraries does not involve the operating system shell
interpreter, and therefore avoids a large number of problems
G. Insecure Cryptographic Storage
with shell commands [1-2, 4-5].
Many web applications do not properly protect
sensitive data, such as credit cards, SSNs, and authentication
credentials, with appropriate encryption or hashing. Attackers For those calls that you must still employ, such as calls to
may steal or modify such weakly protected data to conduct backend databases, you must carefully validate the data
identity theft, credit card fraud, or other crimes [1]. provided to ensure that it does not contain any malicious
content. You can also structure many requests in a manner that
ensures that all supplied parameters are treated as data, rather
H. Failure to Restrict URL Access than potentially executable content. The use of stored
Many web applications check URL access rights procedures or prepared statements will provide significant
before rendering protected links and buttons. However, protection, ensuring that supplied input is treated as data.
applications need to perform similar access control checks These measures will reduce, but not completely eliminate the
each time these pages are accessed, or attackers will be able to risk involved in these external calls. You still must always
forge URLs to access these hidden pages anyway [1]. validate such input to make sure it meets the expectations of
the application in question.
I. Insufficient Transport Layer Protection
Applications frequently fail to encrypt network traffic Another strong protection against command injection is to
when it is necessary to protect sensitive communications. ensure that the web application runs with only the privileges it
When they do, they sometimes support weak algorithms, use absolutely needs to perform its function. So you should not
expired or invalid certificates, or do not use them correctly [1]. run the web server as root or access a database as DBADMIN,
otherwise an attacker can abuse these administrative privileges
J. Unvalidated Redirects and Forwards granted to the web application. Some of the J2EE
Web applications frequently redirect and forward users environments allow the use of the Java sandbox, which can
to other pages and websites, and use untrusted data to prevent the execution of system commands.
determine the destination pages. Without proper validation,

648
 If an external command must be used, any user significantly reduce the likelihood of a problem in this area.
information that is being inserted into the command should be Defining and documenting your site's policy with respect to
rigorously checked. Mechanisms should be put in place to securely managing users is a good first step. Ensuring that
handle any possible errors, timeouts, or blockages during the your implementation consistently enforces this policy is key to
call. having a secure and robust account and session management
mechanism. Some critical area includes:
All output, return codes and error codes from the call  Password Change Controls
should be checked to ensure that the expected processing  Password strength
actually occurred. At a minimum, this will allow you to  Password Storage
determine that something has gone wrong. Otherwise, the  Protecting Credentials in Transit
attack may occur and never be detected.  Session ID Protection
 Account Lists
The OWASP Filters project is producing reusable  Browser Caching
components in several languages to help prevent many forms  Trust Relationship
of injection. OWASP has also released Code Seeker, an
 Backend Authentication
application level firewall.
D. Insecure Direct Object References
B. Cross Site Scripting (XSS) The best protection is to avoid exposing direct object
The best way to protect a web application from XSS references to users by using an index, indirect reference map,
attacks is ensure that your application performs validation of or other indirect method that is easy to validate. If a direct
all headers, cookies, query strings, form fields, and hidden object reference must be used, ensure that the user is
fields (i.e., all parameters) against a rigorous specification of authorized before using it. Establishing a standard way of
what should be allowed. The validation should not attempt to referring to application objects is important:
identify active content and remove, filter, or sanitize it. There
 Avoid exposing private object references to users
are too many types of active content and too many ways of
whenever possible, such as primary keys or filenames
encoding it to get around filters for such content. We strongly
 Validate any private object references extensively with an
recommend a „positive‟ security policy that specifies what is
"accept known good" approach
allowed. „Negative‟ or attack signature based policies are
difficult to maintain and are likely to be incomplete [1, 8-9].  Verify authorization to all referenced objects

Encoding user supplied output can also defeat XSS E. Cross Site Request Forgery (CSRF)
vulnerabilities by preventing inserted scripts from being Applications must ensure that they are not relying on
transmitted to users in an executable form. Applications can credentials or tokens that are automatically submitted by
gain significant protection from JavaScript based attacks by browsers. The only solution is to use a custom token that the
converting the following characters in all generated output to browser will not „remember‟ and then automatically include
the appropriate HTML entity encoding: with a CSRF attack. The following strategies should be
inherent in all web applications [1, 6, 8]:
From: To:  Ensure that there are no XSS vulnerabilities in your
application (see Cross Site Scripting)
< &lt;
 Insert custom random tokens into every form and URL
> &gt; that will not be automatically submitted by the browser.
( &#40;  For sensitive data or value transactions, re-authenticate or
) &#41; use transaction signing to ensure that the request is
# &#35; genuine. Set up external mechanisms such as e-mail or
phone contact in order to verify requests or notify the user
& &#38;
of the request
 Do not use GET requests (URLs) for sensitive data or to
perform value transactions. Use only POST methods
The OWASP Filters project is producing reusable components
when processing sensitive data from the user. However,
in several languages to help prevent many forms of parameter
tampering, including the injection of XSS attacks. OWASP the URL may contain the random token as this creates a
unique URL, which makes CSRF almost impossible to
has also released Code Seeker, an application level firewall. In
perform.
addition, the OWASP Web Goat training program has lessons
on Cross Site Scripting and data encoding.  POST alone is insufficient a protection.

C. Broken Authentication and Session Management F. Security Misconfiguration

Careful and proper use of custom or off the shelf The first step is to create a hardening guideline for your
authentication and session management mechanisms should particular web server and application server configuration.

649
This configuration should be used on all hosts running the  Ensure that all URLs and business functions are protected
application and in the development environment as well. We by an effective access control mechanism that verifies the
recommend starting with any existing guidance you can find user‟s role and entitlements prior to any processing taking
from your vendor or those available from the various existing place. Make sure this is done during every step of the
security organizations such as OWASP, CERT, and SANS way, not just once towards the beginning of any multi-
and then tailoring them for your particular needs. The step process
hardening guideline should include the following topics [1]:  Perform a penetration test prior to deployment or code
delivery to ensure that the application cannot be misused
 Configuring all security mechanisms by a motivated skilled attacker
 Turning off all unused services  Pay close attention to include/library files, especially if
 Setting up roles, permissions, and accounts, including they have an executable extension such as .php. Where
disabling all default accounts or changing their passwords feasible, they should be kept outside of the web root.
 Logging and alerts They should verify that they are not being directly
Once your guideline has been established, use it to configure accessed, e.g. by checking for a constant that can only be
and maintain your servers. If you have a large number of created by the library‟s caller
servers to configure, consider semi-automating or completely  Do not assume that users will be unaware of special or
automating the configuration process. Use an existing hidden URLs or APIs. Always ensure that administrative
configuration tool or develop your own. A number of such and high privilege actions are protected
tools already exist. You can also use disk replication tools  Block access to all file types that your application should
such as Ghost to take an image of an existing hardened server, never serve. Ideally, this filter would follow the "accept
and then replicate that image to new servers. Such a process known good" approach and only allow file types that you
may or may not work for you given your particular intend to serve, e.g., .html, .pdf, .php. This would then
environment. block any attempts to access log files, xml files, etc. that
you never intend to serve directly.
Keeping the server configuration secure requires vigilance.  Keep up to date with virus protection and patches to
You should be sure that the responsibility for keeping the components such as XML processors, word processors,
server configuration up to date is assigned to an individual or image processors, etc., which handle user supplied data
team. The maintenance process should include:
H. Unvalidated Redirects and Forwards
 Monitoring the latest security vulnerabilities published The best way to find out if an application has any
 Applying the latest security patches unvalidated redirects or forwards is to [1]:
 Updating the security configuration guideline
 Regular vulnerability scanning from both internal and  Review the code for all uses of redirect or forward (called
external perspectives a transfer in .NET). For each use, identify if the target
 Regular internal reviews of the server‟s security URL is included in any parameter values. If so, verify the
configuration as compared to your configuration guide parameter(s) are validated to contain only an allowed
 Regular status reports to upper management documenting destination, or element of a destination.
overall security posture  Also, spider the site to see if it generates any redirects
(HTTP response codes 300-307, typically 302). Look at
G. Failure to Restrict URL Access the parameters supplied prior to the redirect to see if they
Taking the time to plan authorization by creating a matrix to appear to be a target URL or a piece of such a URL. If so,
map the roles and functions of the application is a key step in change the URL target and observe whether the site
achieving protection against unrestricted URL access. Web redirects to the new target.
applications must enforce access control on every URL and  If code is unavailable, check all parameters to see if they
business function. It is not sufficient to put access control into look like part of a redirect or forward URL destination
the presentation layer and leave the business logic and test those that do.
unprotected. It is also not sufficient to check once during the
process to ensure the user is authorized, and then not check Safe use of redirects and forwards can be done in a
again on subsequent steps. Otherwise, an attacker can simply number of ways:
skip the step where authorization is checked, and forge the
parameter values necessary to continue on at the next step [1].  Simply avoid using redirects and forwards.
 Enabling URL access control takes some careful  If used, don‟t involve user parameters in calculating the
planning. Among the most important considerations are: destination. This can usually be done.
 Ensure the access control matrix is part of the business,  If destination parameters can‟t be avoided, ensure that the
architecture, and design of the application supplied value is valid, and authorized for the user. It is
recommended that any such destination parameters be a
mapping value, rather than the actual URL or portion of

650
 the URL, and that server side code translate this mapping  All session cookies have their „secure‟ flag set so the
to the target URL.Applications can use ESAPI to override browser never transmits them in the clear.
the send Redirect()method to make sure all redirect  .The server certificate is legitimate and properly
destinations are safe. Avoiding such flaws is extremely configured for that server. This includes being issued by
important as they are a favorite target of phisherstrying to an authorized issuer, not expired, has not been revoked,
gain the user‟s trust. and it matches all domains the site uses.
I. Insecure Cryptographic Storage
The most important aspect is to ensure that everything Providing proper transport layer protection can affect the
that should be encrypted is actually encrypted. Then you must site design. It‟s easiest to require SSL for the entire site. For
ensure that the cryptography is implemented properly. As performance reasons, some sites use SSL only on private
there are so many ways of using cryptography improperly, the pages. Others use SSL only on „critical‟ pages, but this can
following recommendations should be taken as part of your expose session IDs and other sensitive data. At a minimum, do
testing regime to help ensure secure cryptographic materials all of the following:
handling [1]:
 Require SSL for all sensitive pages. Non-SSL requests to
 Do not create cryptographic algorithms. Only use these pages should be redirected to the SSL page.
approved public algorithms such as AES, RSA public key  Set the „secure‟ flag on all sensitive cookies.
cryptography, and SHA-256 or better for hashing.  Configure your SSL provider to only support strong (e.g.,
 Do not use weak algorithms, such as MD5 / SHA1. Favor FIPS 140-2 compliant) algorithms.
safer alternatives, such as SHA-256 or better  Ensure your certificate is valid, not expired, not revoked,
 Generate keys offline and store private keys with extreme and matches all domains used by the site.
care. Never transmit private keys over insecure channels  Backend and other connections should also use SSL or
 Ensure that infrastructure credentials such as database other encryption technologies.
credentials or MQ queue access details are properly
secured (via tight file system permissions and controls), III. WEB APPLICATION HACKING TOOLS AND
or securely encrypted and not easily decrypted by local or MITIGATING SOLUTIONs
remote users
 Ensure that encrypted data stored on disk is not easy to The common Website hacking tools are: [10-14]
decrypt. For example, database encryption is worthless if  IISxploit
the database connection pool provides unencrypted  ASP Trojan or CMD.ASP
access.  Metasploit (Open Source)
 Under PCI Data Security Standard requirement 3, you o 30 Persent Exploit
must protect cardholder data. PCI DSS compliance is  Immunity Framework
mandatory by 2008 for merchants and anyone else dealing o 60 Percent Exploit
with credit cards. Good practice is to never store  Core Impact
unnecessary data, such as the magnetic stripe information o 90 Percent Exploit
or the primary account number (PAN, otherwise known
 Web Inspect
as the credit card number). If you store the PAN, the DSS
 Shadow Security Scanner
compliance requirements are significant. For example,
you are NEVER allowed to store the CVV number (the
The common Web Application hacking tools are:
three digit number on the rear of the card) under any
circumstances. For more information, please see the PCI  Instant Source
DSS Guidelines and implement controls as necessary. View Web Site Source Carefully
 Wget
J. Insufficient Transport Layer Protection Download website and visit offline
 Web Sleuth
The best way to find out if an application has sufficient Scans site for XSS bug
transport layer protection is to verify that [1]:  Window Bomb
Tests website incoming query
 SSL is used to protect all authentication related traffic.  Burp
 SSL is used for all resources on all private pages and Java base application for web Security
services. This protects all data and session tokens that are  CURL
exchanged. Mixed SSL on a page should be avoided since Scans URL for
it causes user warnings in the browser, and may expose Format and Unicode
the user‟s session ID. Characters and structure
 Only strong algorithms are supported.  Black Window
Gets all website files up to the root directory

651
 It's like illegal directory traversal [5] Chip Andrews, David Litchfield, Bill Grindlay, SQL server security,
McGraw-Hill Prof Med/Tech, 2003.
 Acunetix
Best web scanner [6] G. Lawton “Web 2.0 Creates Security Challenges” IEEE Computer
It's very fast and extra feature Society , Vol.40 (10) pp. 13 – 16, 2007.
[7] A. Barth, C. Jackson, J. C. Mitchell Robust defenses for cross-site request
Best References for Bug Track are: forgery, Proceedings of the 15th ACM conference on Computer and
communications security (CCS '08), 2008.

 www.exploit-db.com [8] E. Kirda, C. Kruegel, G. Vigna, N. Jovanovic “Noxes: a client-side

solution for mitigating cross-site scripting attacks” Proceedings of the 2006
 www.security-focus.com ACM symposium on Applied computing(SAC '06), 2006.
 www.nesuss.org
[9] S. Kals, E. Kirda, C. Kruegel , N. Jovanovic, “SecuBat: a web
 www.bugtrack.net vulnerability scanner” Proceedings of the 15th international conference on
 www.bug-tracking.info World Wide Web (WWW '06), 2006.
[10] S. McClure, S. Shah, S. Shah “Web hacking: attacks and defense”
The common ways for increasing website or server security Addison-Wesley Professional, 2003.
are:
[11] J. Mirkovic, S. Dietrich, P. Reiher “Internet denial of service: attack and
 Using Application Firewall defense mechanisms”, Prentice Hall Professional Technical Reference, 2005.
 Administration Account Renaming
[12] Mark Kleiman, When brute force fails: how to have less crime and less
 Disable Default Website punishment, Princeton University Press, 2009.
 Removal of unused application mapping
[13] Lech Janczewski, Cyber warfare and cyber terrorism, Idea Group Inc
 Disable Directory Browsing (IGI), 2008.
 Legal Notices
[14] J. Grossman. Preventing Cross-Site Request Forgeries (CSRF) using
 Always update security patch ModSecurity [Internet]. Version 3. Knol. 2008 Aug 9. Available from:
Service Pack http://knol.google.com/k/jeremiah-grossman/preventing-cross-site-request-
Hotfix forgeries/bn6vj9pl000/17.
 Disable Remote Administration [15] http://www-01.ibm.com/software/tivoli/governance/security/application-
 Check for Malicious input form security.html

IV. CONCLUSION
In the Open System Interconnection (OSI) reference
model, every message travels through seven network protocol
layers. The application layer at the top includes HTTP and
other protocols that transport messages with content, including
HTML, XML, Simple Object Access Protocol (SOAP) and
Web services.
Many hackers know how to make HTTP requests look
benign at the network level, but the data within them is
potentially harmful. Web Application attacks can allow
unrestricted access to databases, execute arbitrary system
commands and even alter Web site content.
Due to the importance of Web Application security, this
paper overviewed the most critical Web Application
vulnerabilities and its fundamental and mitigating solutions,
and also presented the common website and web application
hacking tools. By recognizing the web application
vulnerabilities and solutions, servers could perfume better
against the attackers and malicious activities.

REFERENCES
[1] https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
[2] G. Wassermann, Z. Su “Sound and precise analysis of web applications
for injection vulnerabilities”, Proceedings of the conference on Programming
language design and implementation (ACM SIGPLAN),Vol. 42 (6), 2007.
[3] http://www.ipa.go.jp/index-e.html
[4] Justin Clarke, SQL injection attacks and defense, 2009.

652

View publication stats