CSE 543: Computer Security

Module: Web Security

Prof. Shagufta Mehnaz
Department of Computer Science and Engineering
The Pennsylvania State University

CSE543 - Computer Security Page 1

 Client Side Scripting
• Web pages (HTML) can embed dynamic contents (code) that can be
executed on the browser

• JavaScript
‣ embedded in web pages and executed inside browser

• Java applets
‣ small pieces of Java bytecodes executed in browsers

CSE543 - Computer Security Page 2

 Client Side Scripting
• Browser receives content, displays HTML, and executes scripts
Client-side scripting can access (read/wrtie) the following resources
• Local files on the client-side host
• Webpage resources maintained by the browser:
‣ Cookies,
‣ Domain Object Model (DOM) objects
‣ steal private information
‣ control what users see
‣ impersonate the user

CSE543 - Computer Security Page 3

 Browser as an OS
• Web users visit multiple websites simultaneously
• A browser serves web pages (which may contain programs) from different
web domains
‣ i.e., a browser runs programs provided by mutually untrusted entities
‣ Running code one does not know
‣ A browser also maintains resources created/updated by web domains
• Browser must confine (sandbox) these scripts so that they cannot access
arbitrary local resources
• Browser must have a security policy to manage/protect browser-maintained
resources and to provide separation among mutually untrusted scripts

CSE543 - Computer Security Page 4

 Content from Multiple Sites
• Browser stores cookies from multiple websites
• Q. What is the threat model?
• More generally, browser stores content from multiple websites
‣ HTML pages
‣ Cookies
‣ Flash
‣ Java applets
‣ JavaScript

• How do we isolate content from multiple sites?

‣ malicious sites can attempt to steal other sites’ cookies stored on a browser

CSE543 - Computer Security Page 5

 Same-Origin Policy
• A set of policies for isolating content (scripts and resources) across different
sites (origins)
‣ E.g., evil.org scripts cannot access bank.com resources.
• What is an origin?
‣ site1.com vs site2.com?
• Different hosts are different origins
‣ http://site.com vs https://site.com?
• Different protocols are different origins
‣ http://site.com:80 vs http://site.com:8080?
• Different ports are different origins
‣ Check pg 259 of the textbook by Paul

CSE543 - Computer Security Page 6

 Same-Origin Policy
• Principle: Any active code from an origin can read only information stored in
the browser that is from the same origin
‣ Active code: Javascript, VBScript,…
‣ Information: cookies, HTML responses, ...

Browser SOP Origin A

Origin A
Javascript
Data
Origin A
Javascript
Origin B
Origin B
Origin B
Data

CSE543 - Computer Security Page 7

 Document Domain
• Scripts from two origins in the same domain may wish to interact
‣ catalog.mystore.com and orders.mystore.com
• Site developers finding the DOM SOP too restrictive for their designs can manipulate document.domain, the
domain property of the document object.
• JavaScript in each of two “cooperating” windows or frames whose origins are peer subdomains, say
catalog.mystore.com and orders.mystore.com, can set document.domain to the same suffix (parent) value
mystore.com, explicitly overriding the SOP (loosening it).
• Both windows then have the same origin, and script access to each other’s DOM objects.
• Despite programming convenience, this is seriously frowned upon from a security viewpoint, as a subdomain
that has generalized its domain to a suffix has made its DOM objects accessible to all subdomains of that
suffix (even if cooperation with only one was desired).
• Table 9.1 (page 255 of the textbook by Paul) provides additional information.

CSE543 - Computer Security Page 8

 SOP Weaknesses
• Complete and partial bypasses exist
‣ Browser bugs
‣ Limitations if site hosts unrelated pages
• Example: Web server often hosts sites for unrelated parties
• http://www.example.com/account/
• http://www.example.com/otheraccount/
• Same-origin policy allows script on one page to access document properties from another
‣ Functionality often requires SOP bypass!
• Many advertisement companies hire people to find and exploit SOP browser bugs for cross-domain
communication
• E.g., JSON with padding (JSONP)
• Cross-site scripting (XSS)
‣ Execute scripts from one origin in the context of another
CSE543 - Computer Security Page 9
 Cross-site scripting (XSS)
• Recall the basics
‣ scripts embedded in web pages run in browsers
‣ scripts can access cookies
• get private information
‣ and manipulate/control what users see
• Why would XSS occur
‣ Web applications often take user inputs and use them as part of webpage

CSE543 - Computer Security Page 10

 Cross-site scripting (XSS)
• Assume the following is posted to a message board on your favorite website which
will be displayed to everyone:
Hello message board.
<SCRIPT>malicious code</SCRIPT>
This is the end of my message.
• Anyone who views the post on the webpage can have local authentication cookies
stolen.
• Now a malicious script is running
‣ Applet, ActiveX control, JavaScript…
• Web apps will check that posts do not include scripts, but the check sometimes fail.
• Bug in the web application (i.e., server side). Attack happens in browser.

CSE543 - Computer Security Page 11

 Cross-site scripting (XSS)
• Script from attacker is executed in the victim origin’s context
‣ Enabled by inadequate filtering on server-side
• Effects of Cross-Site Scripting
‣ Can manipulate any DOM component on victim.com
‣ Control links on page
‣ Control form fields (e.g. password field) on this page and linked pages.
‣ Can infect other users: MySpace.com worm
• Three types
‣ Reflected
‣ Stored
• Samy worm

CSE543 - Computer Security Page 12

 Cross-site scripting (XSS)
• Impersonate or masquerade as the victim user
• Carry out any action that the user can perform
• Read or change any data that the user can access or alter
• Capture the user's login credentials (when auto filled by password manager)
• Steal cookies
• Send a message
• Deface the web site
• Initiate interactions with other applications (appear to come from victim)

https://portswigger.net/web-security/cross-site-scripting

CSE543 - Computer Security Page 13

 Cross-site scripting (XSS)
• Impact depends on nature of application
‣ Brochureware application: where all users are anonymous and all information is
public, the impact will often be minimal
‣ Application holding sensitive data, such as banking transactions, emails, or healthcare
records: the impact will usually be serious
‣ If the compromised user has elevated privileges within the application: the impact
will generally be critical

https://portswigger.net/web-security/cross-site-scripting

CSE543 - Computer Security Page 14

 Countermeasures
• Countermeasures include filtering out code and encoding
Filtering approach
● Difficult to remove JavaScript from HTML
● Many ways to embed code other than <script> tag
● Use open-source libraries (ex. jsoup, HTMLawed) that can filter
out JavaScript code

Encoding approach
● Encode data to make JavaScript interpreted as a string
<script>alert(“attack”);</script>
becomes
&lt;script&gt; alert(“attack”);&lt;/script&gt;

CSE543 - Computer Security Page 15

 Countermeasures
• Another countermeasure is to use a nonce in the Content Security Policy (CSP)

Server sends Content-Security-Policy with random nonce in

response header
New nonce generated
Content-Security-Policy: script-src ‘nonce-34fo3er92d’ each time a page is
loaded
Browser only run JavaScript with proper nonce
<script nonce=34fo3er92d>
… JavaScript code…
</script> Nonce matches security
policy nonce, code
<script nonce=abc12345> allowed to run
… JavaScript code
Nonce does not match
</script>
security policy nonce,
code does not run

CSE543 - Computer Security Page 16

 Countermeasures
• Finally, there are tools/processes to find XSS before they are exploited

Tools such as Burp Suite’s vulnerability scanner look for

XSS and other problems in web sites

Can manually test site

• Submit some simple unique input (short alphanumeric
string) to every input point
• Identify every location where submitted input is
returned to browser in HTTP responses
• Examine each location individually

Source: https://portswigger.net/web-security/cross-site-scripting
CSE543 - Computer Security Page 17
 Big picture
• Take away from last few classes: do not trust user input

They can input anything!

CSE543 - Computer Security Page 18

 Web Systems Evolve ...
• The web has evolved from a document retrieval and rendering to sophisticated
distributed application platform providing:
‣ dynamic content
‣ user-driven content
‣ interactive interfaces
‣ multi-site content
‣ ….

• With new interfaces comes new vulnerabilities ...

CSE543 - Computer Security Page 19

 Cross-site Request Forgery
• An XSS attack exploits the trust the browser has in the server to filter input
properly
• A CSRF attack exploits the trust the server has in a browser
‣ Authorized user submits unintended request
• Attacker Maria notices weak bank URL
• Crafts a malicious URL
• Exploits social engineering to get Bob to click the URL

• Can make attacks not obvious

CSE543 - Computer Security Page 20

 CSRF Explained
• More Example:
‣ User logs in to bank.com. Forgets to sign off.
‣ Session cookie remains in browser state
• Then user visits another site containing:
<form name=F action=http://bank.com/BillPay.php>
<input name=recipient value=badguy> …
<script> document.F.submit(); </script>
‣ Browser sends user auth cookie with request
‣ Transaction will be fulfilled
• Problem: The browser is a confused deputy; it is serving both the websites
and the user and gets confused who initiated a request
• https://www.youtube.com/watch?v=5joX1skQtVE&feature=emb_logo

CSE543 - Computer Security Page 21

 CSRF Defense
‣ Referer header: Referer HTTP header contains the URL of the previous page. If you click on a
link on this page, a GET request is done with the URL of this page as the value for the referer
header. This is useful to see where the traffic to your site comes from, but can also be used to
prevent CSRF. Cross site request forgery consists of requests that, by definition, come from
another site. By blocking any request that has another domain in the referer header, you can
block forged requests.

• Bank does not accept request unless referred to (linked from) the bank’s own webpage
• Disadvantage:
‣ privacy issues
‣ can be bypassed: https://www.sjoerdlangkemper.nl/2017/06/21/bypass-csrf-check-using-referrer-policy/

CSE543 - Computer Security Page 22

 Session Hijacking
• Virtual sessions are implemented in many ways
‣ session ID in cookies, URLs
‣ If I can guess, infer, or steal the session ID, game over
‣ Login page using HTTPS, but subsequent communication is not! Cookies sent
in cleartext.
‣ If your bank encodes the session ID in the url, then a malicious attacker can
simply keep trying session IDs until gets a good one.
http://www.mybank.com/loggedin?sessionid=11

‣ Countermeasure: HTTPS, secure cookie design

CSE543 - Computer Security Page 23

 Privacy
• Have you ever …
‣ Searched for a product on some website
‣ ... Advertisement for the same product shows up on another website?
‣ Reason: Tracking! Profile users for targeted advertisement
• Study by WSJ found (2012)
‣ 75% of top 1000 sites feature social networking plugins
• Can match users’ identities with web-browsing activities
• abine and UC Berkeley found
‣ Online tracking is 25% of browser traffic
• 20.28% google analytics
• 18.84% facebook

http://www.abine.com/

CSE543 - Computer Security Page 24

 Privacy
• “Tracker” code is from
‣ Social networking sites
‣ Analytics
‣ Advertisement agencies
‣ …

• Objective of tracking code is to maintain state of users across multiple sites

‣ Build profile of sites visited

CSE543 - Computer Security Page 25

 Third-Party Cookies
• A third-party cookie is a cookie from a website different from the website
being viewed
‣ most frequently used for online advertising
• Browsers can block third-party cookies
‣ Different browsers have different variations
• Some completely block
• “Do Not Track”
• Limitation
‣ Other ways exist to store state
• HTML5 LocalStorage
• Redirect caching

CSE543 - Computer Security Page 26

 Browsers
• Browsers are the new operating systems
• Huge, complex systems that support
‣ Many document types, structures, e.g., HTML, XML, ...
‣ Complex rendering, e.g., CSS, CSS 2.0
‣ Many “program/scripting” languages, e.g., JavaScript
‣ Dynamic content, e.g., AJAX
‣ Native code execution, e.g., ActiveX

CSE543 - Computer Security Page 27

 Browser Security
• We don’t have the ability to control this much complexity, so we have to try
other things ...
‣ Restricting functionality, e.g., NoScript
‣ Process Isolation, e.g., Chrome
• Read: http://www.google.com/googlebooks/chrome/
TAB 1 TAB 2 TAB 3
http://a.com/<img> http://a.com/<img> http://a.com/<img>

http:// http:// http://

<body> <body> <body>
b.com/ b.com/ b.com/
<img> <img> <img>

http:// http:// http:// http:// http:// http://

http://c.com/ http://c.com/ http://c.com/
e.com/ d.com/ e.com/ d.com/ e.com/ d.com/
<img> <img> <img>
<IMG> <IMG> <IMG> <IMG> <IMG> <IMG>

Process 1 Process 2 Process 3

Main Browser Process

CSE543 - Computer Security Page 28

 Drive by downloads
• Using a deceptive means to get someone to install something on their own
(spyware/adware)

‣ Often appears as an error message on the browser

‣ Sometimes, user does not click anything at all!
‣ Concern: extortion-ware -- pay us $ to unencrypt your data
• Used to demand $ for uninstall of annoying software
‣ “biggest cybersecurity threat” - Kaspersky
• Answer (limited): Back up stuff externally that you really want!

CSE543 - Computer Security Page 29

 Social Engineering
• Attacks another weak point -- users!
• Phishing
‣ Lure users using bait (fishing) to steal valuable information
‣ Common technique: mimic original site and use similar URL
• www.aol.com vs www.ao1.com
• Combine with other techniques e.g., turn off address bar

CSE543 - Computer Security Page 30

 Social Engineering
• NYT story on social engineering: Who is making all those scam calls?

https://www.nytimes.com/2021/01/27/magazine/scam-call-centers.html
https://www.youtube.com/watch?v=R1etkjUN6Ak&t=607&start=60

CSE543 - Computer Security Page 31

 Social Engineering
• Social engineering attacks typically begin with Open-Source Intelligence
(OSINT)
‣ Gather intelligence about target from openly available sources
‣ Understand details about target: personal, social, or professional
‣ Adversary can provide credible info later
‣ Most time spent here OSINT

Pretext
development
Attack
plan
Execute
Hadnagy, Christopher. Social engineering: The science of human hacking. Second edition. John Wiley & Sons, 2018.

CSE543 - Computer Security Page 32

 Social Engineering
• After gathering OSINT information, social engineers develop a pretext for an
attack
‣ Plan a cover story
‣ Based on OSINT research

OSINT

Pretext
development
Attack
plan
Execute

CSE543 - Computer Security Page 33

 Social Engineering
• Next social engineers plan their attack, focusing on What, When and Who
‣ Plan out the 3 W’s
• What is the adversary trying to achieve
• When is the best time to attack
• Who is a good candidate to exploit

OSINT

Pretext
development
Attack
plan
Execute

CSE543 - Computer Security Page 34

 Social Engineering
• Finally, social engineers execute an attack, exploiting humans
‣ Familiar but not scripted
‣ Want people to not think too much
‣ Build rapport
‣ Manipulate target
OSINT

Pretext
development
Attack
plan
Execute

CSE543 - Computer Security Page 35

 Social Engineering
• Sometimes you can learn a lot just by passively observing

What can we learn by looking

at this person’s car?

CSE543 - Computer Security Page 36

 Preventing Web System Attacks
• Broad Approaches
‣ Validate input (also called input sanitization)
‣ Limit program functionality
• Don’t leave open ended-functionality
‣ Execute with limited privileges
‣ Input tracking
‣ Source code analysis, e.g., c-cured

CSE543 - Computer Security Page 37

 Conclusion
• Web security has to consider threat models involving several
parties
‣ Web browsers
‣ Web servers
‣ Web applications
‣ Users
‣ Third-party sites
‣ Other users
• Security is so difficult in the web because it was largely retrofitted

CSE543 - Computer Security Page 38

 Thank you!

Questions?

CSE543 - Computer Security Page 39