Introduction to Information Security

9. Web Security

Kihong Heo

1
 Web Security

• What can go wrong on the web through browser-server interactions?

• A lot of sensitive data through the web (e.g., banking)

• A lot of non-trivial code through the web (e.g., JavaScript, SQL Queries)

• Broad impacts on many users worldwide

9. Web Security Introduction to Information Security Kihong Heo 2 / 41

 URL

• Uniform Resource Locator

• Global identi ers of network-retrievable documents

• Example

[Link]

protocol hostname port path query

9. Web Security Introduction to Information Security Kihong Heo 3 / 41

fi
 HTTP
9.1. Web review: domains, URLs, HTML, HTTP, scripts 249

<a href="javascript: stmt1 ; stmt2 ; void 0; ">Click me</a>

4. JavaScript associated with an event handler executes when the event is detected by
the browser. The onload event fires after the document is parsed, all script blocks
• Hypertext Transfer Protocol have run, and all external resources have loaded. All subsequent script execution is
event-driven, and may include JavaScript URLs.
HTTP. Hypertext Transfer Protocol ( HTTP) is the primary protocol for data transfer

• The primary protocol for data transfer between web browsers and servers
between web browsers and servers. A client (browser) first opens a TCP connection to a
server, and then makes an HTTP request consisting of: request-line, header (sequence of
HTTP header lines), and optional body (Fig. 9.2). The request-methods we focus on are

• A stateless protocol: no state is retained across successive requests

GET (no body allowed), POST (body is allowed), and CONNECT (below). The request-URI
is the requested object. The HTTP response is structured similarly with the request-line
replaced by a status-line summarizing how the server fared.

request-line
HTTP-request-hdr HTTP request server
status-line
HTTP-request-hdr
HTTP-response-hdr
opBonal-body HTTP-response-hdr
client HTTP response opBonal-body

<request-method> <request-URI> <HTTP-version>

request-line (example): GET /filepath/[Link] HTTP/1.1
HTTP-request-hdr (examples): Referer: [Link]
Host: [Link]
User-Agent: Mozilla/5.0
<keyword>: <value>
status-line (examples): HTTP/1.1 200 OK
HTTP/1.1 404 Not Found
*Figure from Oorschot’s book
Ch.9. HTTP request Figure 9.2: HTTP
and response. request are
HTTP headers andseparated
HTTP response.
by line-ends
HTTP(CRheader
LF). lines are separated by line-
A blank line (CR LF) precedes the opBonal
ends; a blank body.
line precedes the optional body. The request-URI is generally a local
9. Web Security Introduction to Information Security Kihong Heo 4 / 41
 Cookies

• What happens if all web services are stateless?

• Idea: store a server-created le (cookie) in the browser

• Examples

• Authentication (log in)

• Personalization (language preference, shopping cart)

• User tracking

9. Web Security Introduction to Information Security Kihong Heo 5 / 41

fi
 HTML

• Hypertext Markup Language (i.e., for layout)

• NOT programming language (i.e., for computation)!

• A web page (document) is written in HTML using markup tags

• E.g., <p>, <img>

• Describes a hyper-text document

• E.g., image, audio, video

• What if we need computation?

9. Web Security Introduction to Information Security Kihong Heo 6 / 41

 Script

• HTML may contain program code written in a scripting language

• Make web pages more dynamic

• Most popular: JavaScript

• Web browsers execute the script program

• A webpage gets to execute potentially malicious code on your machine!

9. Web Security Introduction to Information Security Kihong Heo 7 / 41

 DOM

• Document Object Model

• An HTML document: structured data

• Property: content in DOM tree

• Can be modi ed by JavaScript

9. Web Security Introduction to Information Security Kihong Heo 8 / 41

fi
 SW on the Web

• Mix of server-side and client-side code

• Server-side code (e.g., PHP, Ruby, etc) runs on the web server

• Client-side code (e.g., JavaScript, etc) runs in the web browser

request

response

9. Web Security Introduction to Information Security Kihong Heo 9 / 41

 Common Web Security Attacks

• Common examples

• SQL injection

• Cross-site script (XSS)

• Cross-stie Request Forgery (CSRF)

9. Web Security Introduction to Information Security Kihong Heo 10 / 41

SQL Injection

11
 Teaser

By Tanapoom Sermchaiwong
2023 Spring

9. Web Security Introduction to Information Security Kihong Heo 12 / 41

 Teaser

By Tanapoom Sermchaiwong
2023 Spring

9. Web Security Introduction to Information Security Kihong Heo 13 / 41

 SQL Injection

• Common security issues for most web applications that store data in DB

• SQL queries are dynamically constructed by input

• Attack: maliciously manipulate DB via attacker-chosen SQL queries

DB queries HTTP Req

Server-side
Web
Data Application HTML

9. Web Security Introduction to Information Security Kihong Heo 14 / 41

 Example

• A user can log into a web site with a username name and password pw

• An SQL query string is constructed as follows:

name, pw = read_from_input()
query = “SELECT * FROM pswdtab WHERE username=’” + name + “‘ AND password=’” + pw + “‘“
retrieve from this
if each row satis es this condition
all elds table

User: kihong, Password: 1234

query = “SELECT * FROM pswdtab WHERE username=’kihong‘ AND password=’1234‘“

User: root’ --, Password: 1234

query = “SELECT * FROM pswdtab WHERE username=’root‘ —- AND password=’1234‘“

9. Web Security Introduction to Information Security Kihong Heo 15 / 41

fi
fi
 Funny

9. Web Security Introduction to Information Security Kihong Heo 16 / 41

 How to Prevent?

• Secure coding
Sanitize user input
Don’t use user input as code Use parameterized queries
(e.g., &lt; instead of <)
? String userSuppliedParam =
str = input(); [Link]("Product-Description");
mysql_query(str); List<Inventory> list =
[Link]("findByDescription")
.setParameter("productDescription", userSuppliedParam)
.list();
str = substr(input(), 0, 8);
mysql_query(str + “ * FROM tbl”);

• Automated program analysis

• Statically or dynamically check the code before it is shipped

9. Web Security Introduction to Information Security Kihong Heo 17 / 41

Cross-site Script

18
 Teaser

By Tanapoom Sermchaiwong
2023 Spring

9. Web Security Introduction to Information Security Kihong Heo 19 / 41

 Teaser

9. Web Security Introduction to Information Security Kihong Heo 20 / 41

 Simple Script Injection Attack

• Injection of malicious scripts into web pages

• Naive example: send a victim’s cookies to an attacker site

HTTP Req Why this happens and

Server-side
how to prevent?
Web
Application
HTML

Hello World!
<script>
// send all private data
// to [Link]
</script>

9. Web Security Introduction to Information Security Kihong Heo 21 / 41

 Contents from Many Sources

• One HTML document = multiple contents from distinct sources

• Scripts: <script src=“[Link]/[Link]”>

• Frames: <iframe src=“[Link]/[Link]>

• Stylesheets (CSS):
<link rel=“stylesheet” type=“text/css”
href=“[Link]/[Link]">

• What if a script from [Link] can access

data from [Link]?

9. Web Security Introduction to Information Security Kihong Heo 22 / 41

 Same-origin Policy (SOP)

• Basic access control mechanism for web browsers

• Idea: allow a subject to access only the objects from the same origin

• Origin

• For all resources and scripts such as DOM, cookies, JavaScript, etc

• Scripts and images are assigned the origins of the host HTML documents

• E.g., A script from [Link] cannot access data from [Link]

• Designated by <protocol, host, port>

• Same origin as [Link]

1) [Link] 2) [Link] 3) [Link]

9. Web Security Introduction to Information Security Kihong Heo 23 / 41

 258 Example
Chapter 9. Web and Browser Security

client
(browser)
1 pageA1
docA2 domainA
(opened pageA2
by scriptB) 3 docA1 2
(imports [Link] domainB
docC 4 scriptB) Does SOP solve all
(opened the problems?
by scriptB) pageC domainC

// [Link]
Figure 9.5: Same-origin policy 1. in action (DOM into
load pageA2 SOP ). Documents are opened in distinct
docA2
windows or frames. Client creation of docA1
2. load loadsdocC
pageC into content pageA1 from domainA (1).
3. access
Same-origin-policy in ac0on. Documents aredocA2
opened
An embedded tag in pageA1 results in loading
4. access docC scriptB from domainB (2). This script,
in dis0nct windows or frames. Client ac0ons result in crea0on of docA1 loading (1) content pageA1 from
running in docA1,
domainA. Theninherits theitself
(2) pageA1 context of docA1
contains that imported
an embedded tag, which it, and in
results thus mayscriptB
loading access thedomainB.
from
content and properties Q1:
ofdocA1,
docA1. Can scriptB access docA2?
This script, running in runs(3) If docA2
in the context is created
of the by scriptB
document (running
that imported in thus
it, and docA1),
has authority to
Q2: Can scriptB access docC?
loading content pageA2 from the same host (domainA), thenhost,
access the elements of the docA1. Consider the triplet (scheme, port) associated
provided with*Figure
the loading- docA1.
URI ’sfrom Oorschot’s book
(3) If docA2 is created by scriptB (running in docA1), loading content from pageA2 from the same host
scheme and port remain the same, the origins of docA1 and docA2 match, and so scriptB
9. Web Security
(domainA), then provided Introduction
the loading-URL to scheme
Information Security
and port remain the same, the origins ofKihong
docA1Heo and docA2 24 / 41
 Cross-site Script (XSS)

• Injection of malicious scripts into otherwise benign websites

• Bypass SOP by making the pages from benign websites run malicious scripts

• E.g., script origin: [Link], data origin: [Link]

• How to bypass?

• Re ected XSS: pass a malicious script in a parameter of a URL (e.g., query)

• Stored XSS: store a malicious script in the victim server (e.g., bank)

• Etc

9. Web Security Introduction to Information Security Kihong Heo 25 / 41

fl
 Re ected XSS (1)

• Victim (vulnerable) web server, say [Link]

Server User
<?PHP
echo “Welcome! ” . “$_GET[‘user’].”; [Link]/[Link]?user=Kihong
?>

Client Browser Re ection?

<!DOCTYPE html>
<html> Welcome! Kihong
<head>
<title>Victim</title>
</head>
<body>
Welcome! Kihong
</body>
</html>

9. Web Security Introduction to Information Security Kihong Heo 26 / 41

fl
fl
 Re ected XSS (2)

• Victim (vulnerable) web server, say [Link]

Server User
<?PHP
echo “Welcome! ” . “$_GET[‘user’].”; [Link]/[Link]?user=Kihong<script>alert(‘xss’)</script>
?>

Client Browser
<!DOCTYPE html>
<html> Welcome! Kihong
<head>
<title>Victim</title>
</head> xss
OK
<body>
Welcome! Kihong
<script>alert(‘xss’)</script>
</body>
</html>

9. Web Security Introduction to Information Security Kihong Heo 27 / 41

fl
 Re ected XSS (3)

• Entice a user to visit the victim web server with specially crafted queries

• Using phishing mails, attacker’s web sites, etc

“Check this out: [Link] bad…</script>”

• Malicious scripts will run on the user’s machine (origin = victim)

• E.g., steal sensitive data from bank, medical record, email, etc

4 Malicious scripts run

3 Re ection
5 Steal sensitive data
Server-side
Web
Application
1 Malicious URL 2 HTTP Req

9. Web Security Introduction to Information Security Kihong Heo 28 / 41

fl
fl
 Stored XSS Example

• Consider a victim (vulnerable) web forum

• An attacker writes a post that embeds a malicious script

• Malicious scripts will run on the user’s machine (origin = victim)

Good morning!
<script>
// Send all private data to [Link]
</script>

Server-side
Web 3
HTTP response
Inject malicious scripts Application
1
2 HTTP Req

5 Steal sensitive data 4 Malicious scripts run

9. Web Security Introduction to Information Security Kihong Heo 29 / 41

 Real World Examples (1)

9. Web Security Introduction to Information Security Kihong Heo 30 / 41

 Real World Examples (2)

By Dongwoo Moon ( )
2022 Spring

9. Web Security Introduction to Information Security Kihong Heo 31 / 41

9. Web Security Introduction to Information Security Kihong Heo 32 / 41
 How to Prevent XSS?

• Input sanitization: remove potentially malicious elements from data

• E.g., delete tags and event attributes such as <script>, <embed>, etc

• Content security policy (CSP): servers declare trusted sources

• A new security mechanism supported by modern browsers

• CSP: server-side, SOP: client-side

• E.g., disallow all inline scripts

• [Link]

9. Web Security Introduction to Information Security Kihong Heo 33 / 41

 Content Security Policy

• Policy is speci ed in server’s response

• A list of pairs of a directive and values

• Example directives

• default-src: default policy for loading contents

• script-src: de ne valid sources of JavaScript

• img-src: de ne valid sources of images

• Example values: ‘self’, [Link]

9. Web Security Introduction to Information Security Kihong Heo 34 / 41

fi
fi
fi
 Example

• Example:
default-src ‘none’; script-src ‘self’; img-src ‘self’; object-src ‘self’

load scripts, images, and objects from the same origin

but do not load anything

default-src ‘none’; script-src ‘self’ [Link]

load scripts only from the same origin and [Link]

script-src ‘unsafe-inline’

load anything including even inline scripts (Be careful!)

9. Web Security Introduction to Information Security Kihong Heo 35 / 41

Cross-site Request Forgery (CSRF)

36
 Recall: Cookies

• A common usage: authentication

• E.g., log into [Link]

• Once authenticated, subsequent requests will be accepted

• What if an attacker tricks the user to do unwanted actions?

• E.g., send money to the attacker

9. Web Security Introduction to Information Security Kihong Heo 37 / 41

 Cross-site Request Forgery (CSRF)

• Force a user to execute unwanted actions on an authenticated web application

• Trick users with social engineering such as

• URL: <a href=“[Link]/[Link]?to=badguy&amount=100>View my Pictures!</a>

• Invisible image: <img src=“[Link]/[Link]?to=badguy&amount=100 height=0 width=0>

• SOP violation?

9. Web Security Introduction to Information Security Kihong Heo 38 / 41

 How to Prevent CSRF?

• Referrer checking: “where is this request coming from?”

• Accept requests only if their referrer is the same as the server (e.g., *.[Link])

• Secret validation token

• For each session, a fresh secret token is generated by the server

• Send requests with the token

• Accept requests only if the token is valid

9. Web Security Introduction to Information Security Kihong Heo 39 / 41

 Secret Validation Token

// Fake submission page

<form name=BillPayForm action=“[Link]/[Link]>
<input name=recipient value=badguy>
<script>[Link](); </script>

// Valid submission page

<form name=BillPayForm action=“[Link]/[Link]>
<input name=recipient value=friend>
<input type=hidden name=“csrf-token” value=“Jk4j392tjfaijwe”>
<script>[Link](); </script>

9. Web Security Introduction to Information Security Kihong Heo 40 / 41

 Summary

• Web security: safety of browser-server interactions

• Same origin policy: basic access control

• Common vulnerabilities:

Attack Target Attack Method Mitigation

Sanitization
SQL Injection Server Malicious query
Program analysis

Sanitization, CSP,
XSS Server / Client Malicious script
Program analysis

Referrer checking,
CSRF Server / Client Fake request Secret validation token
Program analysis

9. Web Security Introduction to Information Security Kihong Heo 41 / 41