0% found this document useful (0 votes)
18 views17 pages

CSCI6268L17

The document discusses session-based attacks and the use of cookies for session management in web applications. It highlights vulnerabilities such as Cross-Site Scripting (XSS) and the importance of proper security practices to mitigate these risks. The document also emphasizes the need for secure session tokens and the potential dangers of poor random number generation in session IDs.

Uploaded by

SyedAliShahid
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
18 views17 pages

CSCI6268L17

The document discusses session-based attacks and the use of cookies for session management in web applications. It highlights vulnerabilities such as Cross-Site Scripting (XSS) and the importance of proper security practices to mitigate these risks. The document also emphasizes the need for secure session tokens and the potential dangers of poor random number generation in session IDs.

Uploaded by

SyedAliShahid
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 17

Foundations of Network and

Computer Security

John Black

CSCI 6268/TLEN 5550, Spring 2013


Session-Based Attacks
• HTTP is connectionless
– But many/most apps want to maintain state
– Using IP addresses is an imperfect solution
• Why?
– Cookies were invented to solve exactly this
problem
Using Cookies for Session
Management
• The server wants to maintain information
about the current client
– Encode state into an alphanumeric string
– Use Set-cookie=string and send to browser
• Optionally set expires, domain, path, secure, httponly
values as well
– Now each time the browser wishes to connect
to a given domain and path, it checks its
cookie store and transmits all matching
cookies
Using Cookies for Session
Management
• They are essentially a temporary password
– Difficult to guess, not short enough to brute-force,
unique
• These are often violated by using insufficient randomness,
being too short, using counters, etc
• Many apps that lock-out password attempts fail
to guard against brute force attacks on session
ids
– So short session ids are very vulnerable
– Demo stateful.php on moxie
Bad Random Number
Generators
• Netscape Session Keys – 1996
– RNG_CreateContext()
– /* time since Jan 1, 1970 */
– (seconds, microseconds) = time of day;
– pid = process ID; ppid = parent process ID;
– a = mklcpr(microseconds);
– b = mklcpr(pid + seconds + (ppid << 12));
– seed = MD5(a, b);
– mklcpr(x) /* not cryptographically significant */
– return ((0xDEECE66D * x + 0x2BBB62DC) >> 1);
Cross-Site Scripting (XSS)
• XSS is a very common vulnerability
– Would be vulnerability of the decade except
SQL injections are often far more serious
– XSS is used for a client to attack another
client, not to attack a server
• An XSS vulnerability is as simple as
echoing back user-input without sanitizing
– Ex: You submit: “XYZ!!(2” to a search engine
and it replies with “XYZ!!(2 no results found”
“Security Context”
• We define a security context to be the set
of rules that govern how cookies are
handled between domains
• Users might have several contexts active
at the same time
– Ex: An unexpired session token with a bank
sitting in another browser window (logout or
browser death usually purges these tokens,
but users will often neglect to do either)
XSS
• The idea of XSS is for an attacker to inject
malicious javascript into a security context
that it does not own
– And, as we know, this means things like
session tokens can be sent anywhere we like
user connects to evil site

javascript executes as if
from bank; tokens stolen

Link to bank with malicious


malicious javascript javascript given as parameter
reflected back to user
with bank’s security
context

Typically called
“reflected” XSS
Demo on moxie
• Visit stateful.php to establish highly
valuable session ID
• View xss.php behavior
• Look at ~drevil on moxie
– Note the warm innocent feel of the page
– View source on this page (note the
encodings)
• Examine steal.php
• Click on link on drevil’s homepage
– Look in /tmp/stolen.txt
Stored XSS
• Stored XSS is very similar
– Instead of using a reflection bug, the attacker
stores javascript in a place where the victim is
likely to read it (and thereby execute it)
– It’s usually the server’s responsibility to sanitize
user input before storing it
• Consider a public forum where various users post their
thoughts
– And their exploit code…
– Stored XSS is usually considered more serious
• No need to induce the user to establish a session then
visit drevil’s site, which can be hard some times
Note proper
domain name

SSL would be enabled,


if this were an SSL site
Samy XSS worm
• Oct, 2005: myspace had an XSS
vulnerability
– They used <script> filters, but 19-yr old Samy
Kamkar found a way to bypass all of them
– He built an AJAX app so that every view of his
profile added him as a friend and posted “…and
most of all, Samy is my hero” to their page
– He also had the worm install itself so that any
viewer of the page would propagate the worm
Three years
probation, 90 days
community service,
and a book-deal
Finding XSS Vulnerabilities
• Try entering
in every
><script>alert(document.cookie)</script>
user-input vector and monitor for appearance
of this string from the site
– If string comes back unmodified, jackpot
• This is automatable
• Some XSS vulns will not be found by this technique,
however, since <script> is often filtered out (as are <
> /)
• Some XSS filters will miss ><script >, ><ScRiPt>,
%3e%3cscript%3e, ><scr<script>ipt>, %00><script>
Good Practices (for security)
• Create a session token on first visit
• When performing authentication, destroy the
old session and create a new one
• Expire sessions after a short period (30-60
mins)
• Destroy sessions after logout
• Use SSL and mark session cookies as secure
• Monitor User-Agent header; it shouldn’t change
during a session

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy