This document discusses Cross-Site Request Forgery (CSRF) attacks using JSON. It begins with background on CSRF, JSON, and mitigation techniques. It then explores how normal CSRF attacks may fail with JSON payloads and proposes three cases to bypass these failures: 1) Adding an extra parameter, 2) Using XMLHttpRequest or Fetch API, 3) Leveraging Flash and Crossdomain.xml for redirection. Defenses include synchronizer tokens, double cookies, encrypted tokens, and CAPTCHAs. The document provides references and invites questions.
2. Table of Content
Sr No. Topic Page
1 Basic introduction 3
2 CSRF with JSON 10
3 Demo 18
4 Mitigation 22
5 Reference 23
6 Questions 24
3. Basic Introduction
• Cross-Site Request Forgery –
Attacker forces an victim to execute unwanted actions on a web application in which they're
currently authenticated.
- Its state changing attack not an data theft.
- Cookies are intrinsically vulnerable.
• JavaScript Object Notation –
Exchange of data between a browser and a server, the data can only be text.
- Any JavaScript object can be converted in to JSON and vice versa.
- JSON is lightweight, easy to understand and language independent.
{"name":"John","age":30,"city":"New York"}
4.
5. • Same-Origin Policy –
It restricts how a document or script loaded from one origin can interact with a resource from
another origin. It is a critical security mechanism for isolating potentially malicious documents.
− Same origin if the protocol, port and host are the same
− Protects the confidentiality and integrity of information
6. • Cross Origin Resource Sharing–
Is a mechanism that uses additional HTTP headers to let a user agent gain permission to access
selected resources from a server on a different origin.
- Bypasses SOP.
- Access image, script, CSS and lot more.
7. • Flash and Crossdomain.xml–
Flash files can contain video, animations, sound and interactive content written in ActionScript
which are designed for efficient delivery over the web. It can be viewed in a web browser using
the Flash plug in.
- Extension for flash file is SWF stands for Small Web Format.
• Crossdomain.xml file is a cross-domain policy file that grants flash players to access the
resources other than it is hosted on.Here we can see that amazon.com server only allows
flash files from certain domains to access its resources.
8. • XMLHttpRequest and Fetch API–
Its an API that can be used scripting languages to transfer and manipulate XML data to and
from a webserver using HTTP, establishing an independent connection channel between a
webpage's Client-Side and Server-Side.
- You can retrieve data from a URL without having to do a full page refresh.
- This enables a Web page to update just part of a page without disrupting what the user is
doing.
- The Fetch API provides an interface for fetching resources. It is similar to XHR, but the new API
provides a more powerful and flexible feature set.
12. This technique may fail in some cases when the server side JSON parsers reject the incoming JSON because of the
trailing ‘=’ character.
13. • CASE: 1
- Bypassing trailing equal to sign by ignore_me parameter.
14. These may only help, if the application allows to smuggle in extra parameter into the request or application not
validating Content-type.
15. • CASE: 2
- If extra padded parameter not allowed then using XHR or FETCH to generate CSRF POC.
function submitRequest()
{
var xhr = new XMLHttpRequest();
xhr.open("POST", "https://example.com/", true);
xhr.setRequestHeader("Accept", "application/json");
xhr.setRequestHeader("Accept-Language", "en-US,en;q=0.5");
xhr.setRequestHeader("Content-Type", "text/plain");
xhr.withCredentials = true;
var body = '{"name":"attacker","email":"attacker.com"}’;
var aBody = new Uint8Array(body.length);
for (var i = 0; i < aBody.length; i++)
aBody[i] = body.charCodeAt(i);
xhr.send(new Blob([aBody]));
}
17. - Browser sends pre-flight request to verify.
- Origin is set to attacker’s site
- Server reject further request
18. • CASE: 3
- If application is validating the Content-type and data format, this attack can be achieved
using flash , Crossdomain.xml and 307 redirect.
21. - Steps :
1) Authenticated user loads the attacker web page
containing malicious Flash file
2) Flash file made an XMLHttpRequest to attackers domain,
before doing that, the browser checks whether attacker
domain allows flash requests via crossdomain.xml file.
3) Victim browser then made an actual post request to
attacker’s domain, with post data that needs to send to
the vulnerable domain.
4) The attacker sends response with 307 redirect, which
means send POST data to the value of location header.
5) The victim browser then sends actual POST request
containing attacker’s payload to the vulnerable domain
with necessary headers.
22. Mitigation
1. Synchronizer (i.e.,CSRF) Tokens (requires session state)
2. Double Cookie Defence
3. Encrypted Token Pattern
4. Custom Header - e.g., X-Requested-With: XMLHttpRequest
• The following are some examples of challenge-response options:
1. Re-Authentication (password or stronger)
2. One-time Token
3. CAPTCHA