Dynamic Cross-Site Request Forgery

(CSRF)
11/08/09 12:34 Filed in: Application Security

Bypassing

CSRF

Protections

With

Dynamic

CSRF

At our presentation at Black Hat and Defcon this year, Shawn Moyer and I gave a talk
calledWeaponizing the Web: More Attacks on User Generated Content. During the talk we
discussed something we are calling Dynamic Cross-Site Request Forgery (CSRF). Dynamic
CSRF methods can be used to create new attack vectors and compromise CSRF protection
mechanisms. CSRF is often difficult to explain in the first place, so I just wanted to do a post
about

it

Static

and

link

our Dynamic

CSRF

CSRF

White

Paper.

Attacks

The current way people are exploiting CSRF issues is pretty static. A link may be crafted and
people are tricked in to clicking on it or viewing a page with this link embedded. They may
even do something such as create an auto-submitting POST that the user executes when
visiting certain content. The moral is that someone crafts this attack for a specific location and
chooses a vector for delivering it to users. On its own, this static CSRF attack method can be
pretty devastating or perhaps totally innocuous. Thats just the nature of CSRF. There arent
too many vulnerabilities that fall in to this category, which may be why it can sometimes be
hard

to

understand.

Lets just think about some things that would make CSRF even more dangerous. What if we
had visibility in to CSRF tokens or even session identifiers? What if we knew for sure a user
was on the site that we wanted to attack? What if we could use a central point to dynamically
attack multiple sites? What if we could create a custom payload on the fly to include tokens
and session data? What if we could request data in another process and fixate it on to a
request that the user executes? CSRF would become much more dangerous. Well, it just did.

Dynamic

CSRF

Attacks

With Dynamic CSRF attacks the game changes a bit. Attacks can be adapted based on where
requests are originating from. Sensitive information sent in a cross-domain fashion can be
packaged in to a customized payload and sent to a location. Disjoined or bolted on
components can be queried and fixated on to a users request. This opens up new
opportunities for attacks. Dynamic CSRF allows you to run one central system and run attacks
for multiple sites and applications with the ability to remove and repackage any leaked session
information.

Using dynamic methods may allow for the bypass of CSRF protections. Whether these
protections are leaked in the referer or if they can be requested by other means and fixated on
to the request, bypassing may be possible. This makes requests that were previously not
vulnerable

to

CSRF

vulnerable

again.

When not limited by static requests a few new attack vectors open up. I just wanted to
highlight

couple

Getting

here.

Dynamic

In the next couple of sections I am going to point out some dynamic methods for bypassing
CSRF

protection

mechanisms.

HTTP

Redirect

A simple redirect attack can be made more devastating with the addition of session related
data added to the request. So a user hits a piece of HTML on a web page that sends a GET
request containing session data (Session IDs, CSRF Tokens, etc) in the referer. This session
data can be taken from the referer and repackaged in to a payload that is sent to the users
browser

as

location

for

302

redirect.

A scenario for this type of attack might be embedding a hidden image tag that links to a
location offsite. This image tag may leak session data through referer allowing a tool to
repackage that session data and get the users browser to execute it as a payload. This could
be used to bypass CSRF protections by using the CSRF tokens from the referer.

HTML-based

Redirect

For this scenario a hyperlink could point to a page that is created dynamically per-each
request. This page contains a hidden GET or POST that could contain session data taken from
referer as mentioned previously in the HTTP Redirect. The page would then refresh to a
legitimate destination. To a user there would only appear to be a short pause prior to their
landing on the legitimate destination, but in the background an attack has happened.
This attack could be made more interesting with URL shortening services. People have become
accustomed to URL shorteners due to their use of Twitter and other social networks. Using a
URL shortener would mask the location of the dynamic page and may not raise further
suspicion.

A scenario for this would be posting a link that is shortened with a URL shortener on a web
site that supposedly links to a video on YouTube. When the user clicks the link a hidden action
(GET or POST) is executed. After the hidden action takes place, the browser does a refresh to
the expected destination (the YouTube video). The victim may get little or no indication that
the

hidden

attack

Fixation

has

Based

happened.

Attacks

Here is where things get a bit interesting. This attack hinges on the ability to have a valid CSRF
token and a valid session identifier, but those two values arent associated together from a
session perspective. Say you are posting on a message board. This message board issues you
a Session ID in a cookie and also issues you a token for use when posting. If these two values
arent linked from a session perspective, it would allow for any valid token to be added to the
request. Since the Session ID is in the cookie value, if a forged request had a valid token
appended

this

would

bypass

CSRF

protections.

What makes this fixation attack an interesting scenario is it requires no leaking of any session
data in a cross domain fashion. As long as you have some visibility to the token, it can be
requested

and

fixated

to

the

Other

request.

Scenarios

There are other scenarios as well. It really depends on how much session data gets leaked in a
cross-domain fashion. For example, if the full session ID is leaked, there could be some real
problems. It could allow for a tool to construct any GET or any POST to the target application.

MonkeyFist
MonkeyFist is a tool I wrote to PoC Dynamic CSRF attacks. The tool runs as a small service on
a system listening for all incoming input. When it receives a request it looks in the referer to
determine where the request is coming from. It then uses this information to parse a payloads
file and look for the specific attack to construct for that domain. You can have multiple entries
in the payloads file performing multiple types of attacks. Redirect, POST, Page (GET and POST)
and an Experimental Fixation handler are all included in the application. You can learn more
about MonkeyFist on the the Hexsec Labs page. It is not exactly where I would like it to be,
but it works. More streamlining and modifications will come soon. I am still recovering from
Black
I

have

More

Hat
some

posts

and
on

MonkeyFist

Defcon
that

are

coming

soon

as

well.

Info

Thats it for a quick intro to Dynamic CSRF. If you would like more information you can read
our white paper which is availablehere.
Tags: Bypassing CSRF Protections, cross-site request forgery, csrf, Dynamic CSRF, Token
Fixation