This document discusses various client-side attacks that can be performed against web browsers and applications. It covers techniques like keylogging, stealing browser history, port scanning the local network, exploiting DNS rebinding to bypass same-origin policy, and using browser exploitation frameworks. The goal of these attacks is to steal sensitive user data, hijack user sessions on other sites, or pivot to other systems on the local network. Defenses discussed include preventing caching of sensitive data, using POST instead of GET, and restricting ports accessible to JavaScript.

1. CNIT 129S: Securing
Web Applications
Ch 13: Attacking Users:
Other Techniques (Part 2)
Updated 4-30-2020

2. Other Client-Side Injection
Attacks

3. HTTP Header Injection
• Suppose user speci
fi
es a language in a GET
request parameter
• Response contains the language in a cookie

4. HTTP Header Injection
• User-controlled data in an HTTP heade
r
• Most commonly the Location and Set-Cookie
headers

5. • If you can inject %0d%0a, you can add a new header
line
• Send this request
:
• Get this reply:
Injecting Another Header

6. Exploiting Header Injection
• See if %0d and %0a return decoded as carriage-
return and line-fee
d
• If only one works, you may still be able to
exploit i
t
• If they are blocked or sanitized, try these
bypasses

7. Injecting Cookies
• Send this request
:
• Get this reply:
• Cookies may persist across browser sessions

8. Delivering Other Attacks
• HTTP header injection allows an attacker to
control the entire body of a respons
e
• Can deliver almost any attac
k
• Virtual website defacemen
t
• Script injectio
n
• Redirection

9. HTTP Response Splitting
• Inject a second complete page into the header
s
• Must inject carriage returns and line feeds

11. Poisoning the Cache on a
Proxy Server

12. Preventing Header Injection
• Don't insert user-controllable input into header
s
• If you must, us
e
• Input validation (context-dependent
)
• Output validation: block all ASCII characters
below 0x20

13. Cookie Injection
• Attacker sets or modi
fi
es a cookie in the victim
user's browse
r
• This may be possible if
:
• App has functionality that takes a name and
value from parameters and sets those within a
cookie, such as "Save user preferences
"
• HTTP header injection vulnerability

14. Cookie Injection
• Setting a malicious cookie via XS
S
• XSS in related domains can be leveraged to
set a cookie on the targeted domain, from any
of these
:
• Any subdomain of the target domain, any of
its parents and their subdomains

15. Cookie Injection
• Setting a malicious cookie via a Man-in-the-
middle (MITM) attac
k
• MITM attacker can set cookies for arbitrary
domain
s
• Even if the targeted app uses only HTTP and
all its cookies are
fl
agged as "secure
"
• Using sslstrip

16. Consequences of Setting a
Cookie
• Some apps may change their logic in response
to cookie values, such as UseHttps=fals
e
• Client-side code may trust cookie values and
use them in dangerous ways, leading to DOM-
based XSS or JaScript injectio
n
• Some apps implement anti-CSRF tokens by
placing the token into both a cookie and a
request parameter and comparing the
m
• If an attacker controls both, this defense can
be bypassed

17. Consequences of Setting a
Cookie
• If an app has a same-user persistent XSS vul
n
• You can use CSRF to trick the user into
loading the script, but you can perform the
same attack by putting your own session
token into the user's cooki
e
• Exploit session
fi
xation vulnerabilities

18. Session Fixation
• Suppose an app creates an anonymous session
for each user before logi
n
• When the user logs in, the session is
upgraded to an authenticated sessio
n
• Using the same toke
n
• In session
fi
xation, attacker gets an anonymous
token and
fi
xes it within the victim's browse
r
• When victim logs in, the token gains
privileges

20. How to Inject the Token
• Cookie injection (if token is in a cookie
)
• If session token is in the URL, feed victim a URL
like thi
s
• Some apps let you add a token in the URL after
a semicolon, even if this isn't the defaul
t
• If session token is in a hidden HTML
fi
eld, use
CSRF

21. • Anonymous user browses product
s
• Places items into a shopping car
t
• Checks out by submitting personal data and
payment detail
s
• Reviews data on a Con
fi
rm Order pag
e
• Attacker
fi
xes an anonymous token in target's
browser and views the Con
fi
rm Order page to
steal data
Session Fixation Without Login

22. Arbitrary Tokens
• Some apps accept arbitrary tokens submitted
by user
s
• Even if they were not issued by the server
itsel
f
• App creates a new session using the toke
n
• Microsoft IIS and Allaire ColdFusion did
this in the pas
t
• So attacker can just send target a link with an
arbitrary token

23. Finding and Exploiting
Session Fixation Vulnerabilities
• Review handling of session tokens in relation to
logi
n
• Two vulnerabilitie
s
• App assigns token to anonymous user and
upgrades its privileges upon logi
n
• User who logs in, then logs in again to a
different account, retains the same token

24. • In either case, an attacker can obtain a valid
session token and feed it to the target use
r
• When that user logs in, the attacker can hijack
the sessio
n
• Even without a login, the app may reveal
sensitive information to an attacker with the
target's session token
Finding and Exploiting
Session Fixation Vulnerabilities

25. Preventing Session Fixation
• Whenever a user transitions from being
anonymous to being identi
fi
ed, issue a fresh
session toke
n
• This applies to both login and when a user
fi
rst submits personal or other sensitive
informatio
n
• For defense-in-depth, employ per-page tokens to
supplement the main session toke
n
• App should not accept arbitrary session tokens
that it does not recognize as being issued itself

26. Open Redirection
• App takes user-controllable input and uses it to
redirect to a different UR
L
• Commonly used for Rickrollin
g
• Useful in phishing attacks, to make a fake page
appear to be in the target domai
n
• Most real-world phishing attacks use other
technique
s
• Registering similar domain names, using
of
fi
cial-looking subdomains, or using anchor
text that doesn't match the URL

27. Types of Redirects
• 3xx status cod
e
• HTTP Refresh header (number is delay in
seconds)

28. • HTML <meta> tag
Types of Redirects

29. • JavaScript API
Types of Redirects

30. • Most redirects are not user-controllabl
e
• One common place they are is when app has
"return to original page" functionalit
y
• For example, after a timeout and re-logi
n
• Look for URLs that contain a domain name and
try changing it
Exploiting Open Redirects

31. • Open redirect misidenti
fi
ed by ZAP as RFI

32. Filtering or Sanitizing URLs
• Some apps try to prevent redirection attacks b
y
• Blocking absolute URL
s
• Adding a speci
fi
c absolute URL pre
fi
x

33. Blocking Absolute URLs
• Block user-supplied strings that starts with
"http://
"
• These tricks might work

34. Sanitizing Absolute URLs
• Remove "http://" and any external domain
• Previous tricks might work, and these:

35. • App may verify that the user-supplied string
starts with, or contains, an absolute URL to its
own domain nam
e
• Try these:
Sanitizing Absolute URLs

36. Adding an Absolute Pre
fi
x
• App forms target of redirect by appending the
user-controlled string to an absolute URL pre
fi
x

37. Adding an Absolute Pre
fi
x
• If the added pre
fi
x is "http://mdsec.net" instead
of "http://mdsec.net/", it's vulnerable

38. Preventing Open
Redirection Vulnerabilities
• Don't incorporate user-supplied data onto the
target of a redirec
t
• It's better to have a list of allowed redirection
targets, and only allow known good choices

39. Preventing Open
Redirection Vulnerabilities
• If you must use user-controlled data
:
• Use relative URLS in all redirects, and the
redirect page should verify that the user-
supplied URL begins with a single slash
followed by a letter, or begins with a letter and
does not have a colon before the
fi
rst slas
h
• Prepend every URL with http://domain.com
/
• Verify that every URL starts with
http://domain.com/

40. Client-Side SQL Injection
• HTML5 supports client-side SQL database
s
• Accessed through JavaScript, like thi
s
• Allows apps to store data on the client sid
e
• Allows apps to run in "of
fl
ine mode"

41. • Attacker may be able to steal data such a
s
• User's contact information from social
networking app
s
• Comments from news app
s
• Email from web mail app
s
• Attacks such as sending SQLi in the subject of
an email
Client-Side SQL Injection

42. Client-Side HTTP Parameter
Pollution
• A web mail app loads the inbox with this URL
:
• This link allows the user to reply to a message,
and it uses several parameters from the inbox
URL:

43. • Attacker tricks target into opening an inbox with
this parameter
:
• This makes the "Reply" link look like this, so it
deletes messages instead:
Client-Side HTTP Parameter
Pollution

44. Ch 13b-1

45. Local Privacy Attacks

46. Shared Machines
• Attacker has access to the same computer as
the target use
r
• Similar situation: a stolen cell phone or laptop

47. Persistent Cookies
• Cookies often have expiration dates far in the
futur
e
• Especially on mobile devices

48. Cached Web Content
• Browsers typically cache non-SSL content
unless told not to, by HTTP response headers or
HTML metatags

49. Browsing History &
AutoComplete
• Browsing history may include sensitive data in
URL parameter
s
• Autocomplete often stores passwords, credit
card numbers, etc
.
• IE stores autocomplete data in the registry,
Firefox stores it in the
fi
le syste
m
• Autocomplete data can be stolen by XSS under
some circumstances

50. Flash Local Stored Objects
• Also called "
fl
ash cookies
"
• Shared between different browsers, if they have
the Flash extension installe
d
• Used by Google and other companies to mark
your computer in a way that's dif
fi
cult to erase

51. Internet Explorer userData
• IE's custom user data storage syste
m
• Edge stores local data even in Private Browsing
mod
e
• Link Ch 13e

52. HTML5 Local Storage
Mechanisms
• HTML5 introduced a range of new local storage
mechanisms, including
:
• Session storag
e
• Local storag
e
• Database storag
e
• The speci
fi
cations are still evolving; privacy
implications are not clear

53. Preventing Local Privacy
Attacks
• Apps shouldn't store anything sensitive in a
persistent cooki
e
• Even if it's encrypted, because the attacker
could replay i
t
• Apps should use cache directives to prevent
sensitive data being stored by browsers

54. • ASP instructions to prevent cachin
g
• Java commands:
Preventing Local Privacy Attacks

55. • Apps shouldn't use URLs to transmit sensitive
dat
a
• Because URLs are logged in numerous
location
s
• All sensitive data should be transmitted with
POS
T
• Sensitive
fi
elds should use the
"autocomplete=off" attribute
Preventing Local Privacy Attacks

56. Attacking the Browser

57. Logging Keystrokes
• JavaScript can monitor all keys pressed while
the browser window has the focu
s
• This script captures all keystrokes in Internet
Explorer and displays them in the status bar

58. Works on Old Win 2008

59. Keylogger Demo

60. Works in Brave

61. Logging Keystrokes
• Can only capture keystrokes while the frame
running the code is in focu
s
• Apps are vulnerable when they embed a third-party
widget or advertising applet in a frame within the
app's own page
s
• In "reverse strokejacking", malicious code in a child
frame can grab the focus from the top-level windo
w
• It can echo the keypresses to the top-level
window so the app appears to be working
correctly

62. Stealing Browser History
and Search Queries
• JavaScript can brute-force common websites to
see which ones have been visited via the
"getComputerStyle" AP
I
• This was
fi
xed in 2010 (link Ch 13f)

63. Enumerating Currently Used
Applications
• JavaScript can determine whether the user is
currently logged in to third-party application
s
• By requesting a page that can only be viewed by
logged-in users, such as "My Details
"
• This script uses a custom error handler to
process scripting error
s
• And then makes a cross-domain request

64. • Since the "aspx" page contains HTML, not
script, the request always causes a JavaScript
erro
r
• But the error will have a different line number
and error typ
e
• So the attacker can deduce whether the user is
logged in or not
Enumerating Currently Used
Applications

65. Port Scanning
• Browser-based port scanning from a Java apple
t
• BUT same-origin policy means browser can't see
the respons
e
• Attempt to dynamically load and execute
script from each targeted host and por
t
• If a Web server is running on that port, it
returns HTML or some other conten
t
• Resulting in a JavaScript error the port-
scanning script can detect

66. • Most browsers implement restrictions on the
ports that can be accessed using HTTP
request
s
• Ports commonly used by other well-known
services, such as port 25, are blocked
Port Scanning

67. Attacking Other Network
Hosts
• After a port scan identi
fi
es other hosts running
HTTP server
s
• A script can attempt to
fi
ngerprint them by
looking for known
fi
le
s
• This image is present on a certain brand of DSL
routers:

68. • After identifying the device, attacker can try
default username and passwor
d
• Or exploit known vulnerabilitie
s
• Even if attacker can only issue requests but not
see responses, many attacks are possible
Attacking Other Network
Hosts

69. Exploiting Non-HTTP
Services
• Attacker can send arbitrary binary content to a
por
t
• But it will always start with an HTTP heade
r
• Many network services tolerate the
unrecognized HTTP header
s
• And still process subsequent input that is
correctly formed

70. XSS Attacks from Non-HTTP
Services
• Non-HTTP service running on a port that is not
blocked by browser
s
• Non-HTTP service tolerates unexpected HTTP
header
s
• Non-HTTP service echoes part of the request
content in its response, such as an error messag
e
• Browser must tolerates responses that don't have
valid HTTP headers, and process part of the
response as HTML (all browsers do this for
backward compatibility)

71. • Browser must ignore port number when
segregating cross-domain access to cookies
(they do)
• Under those conditions, attacker can send
script to the non-HTTP service, which goes back
to the user's browser and steals cookies
XSS Attacks from Non-HTTP
Services

72. Exploiting Browser Bugs
• Bugs in browser or extensions may be
exploitable with JavaScript or HTM
L
• Java bugs have enabled attackers to perform
two-way binary communication with non-HTTP
services on the local computer or elsewhere

73. DNS Rebinding
• A way to evade the same-origin polic
y
• Attacker has a malicious website and a
malicious authoritative DNS serve
r
• User visits a malicious page on the attacker's
serve
r
• That page makes Ajax requests to the attacker's
domain, which resolves them to the target
domain's IP address

74. • Subsequent requests to the attacker's domain
name are sent to the targeted applicatio
n
• Browser thinks the target app is in the attacker's
domain, so the same-origin policy doesn't block
responses
DNS Rebinding

75. Limitations of DNS
Rebinding
• Host: parameter will point to the attacker's
domai
n
• Requests won't contain the target domain's
cookie
s
• This attack is only useful in special situations,
when other controls prevent the attacker from
directly accessing the target

76. • Link Ch 13j

78. Browser Exploitation
Frameworks
• Such as BeEF or XSS Shel
l
• Use a Javascript hook placed in the victim's
browse
r
• By tricking them into visiting a malicious
page, or using a vulnerability such as XSS

79. • Possible attacks
Browser Exploitation
Frameworks

80. Man-in-the-Middle Attacks
• If app uses unencrypted communications, an
attacker in the middle can intercept sensitive
data like tokens and password
s
• But apps that use HTTPS can be attacked as
well, if it loads any content over HTT
P
• Or even if it doesn't

81. Separation of HTTP and
HTTPS
• Many apps, like Amazon, use both HTTP and
HTTP
S
• Browser separates HTTP cookies from HTTPS
cookies, even for the same domai
n
• But consider a page that loads script over HTTP

82. MITM Attack
• MITM can modify any HTTP response to force
user to reload that page over HTTP
S
• The script will still load over HTT
P
• Without a warning message (in some
browsers
)
• Attacker can inject script into the response,
which has access to the HTTPS cookies

83. HTTPS-Only Domains Like
Google
• Attacker can still induce the user to make
requests for the target domain over HTT
P
• By returning a redirection from an HTTP
request to a different domai
n
• Even if servers don't listen on port 80, MITM
attacker can intercept those requests and
respond to them

84. • Ways to escalate HTTP to HTTPS acces
s
• Set or update a cookie that is used in HTTPS
request
s
• This is allowed even for cookies that were
originally set over HTTPS and
fl
agged as
secur
e
• Cookie injection can deliver an XSS exploit
HTTPS-Only Domains Like
Google

85. • Ways to escalate HTTP to HTTPS acces
s
• Some browser extensions don't separate
HTTP and HTTPS conten
t
• Script can leverage such an extension to read
or write the contents of pages that the user
accessed using HTTPS
HTTPS-Only Domains Like
Google

86. Ch 13b-2