读取型CSRF-需要交互的内容劫持

- [Preface](#preface)  
- [Read-only CSRF](#read-only-csrf)  
  - [JSONP Hijacking](#jsonp-hijacking)  
    - [Vulnerability Case](#vulnerability-case)  
    - [Case Summary](#case-summary)  
  - [Flash Cross-Domain Hijacking](#flash-cross-domain-hijacking) 
  - [Vulnerability Case](#vulnerability-case-1) 
  - [Case Summary](#case-summary-1) 
  - [CORS Cross-Domain Resource Reading](#cors-cross-domain-resource-reading)  
    - [Vulnerability Case](#vulnerability-case-2)  
    - [Case Summary](#case-summary-2)  
- [Conclusion](#conclusion)

# Preface

Lately, while hunting for vulnerabilities, I’ve come to deeply appreciate the saying "practice leads to true knowledge." During actual vulnerability discovery, I reflect on many aspects. Together with a friend, we’re working on compiling a handbook, and this process has led me to rethink the definitions and standards of certain vulnerabilities.

To most people, CSRF is primarily associated with **write-type** actions—such as modifying personal information or authorizing logins. These scenarios are typically classified as medium or high-risk threats. Perhaps because interactive vulnerabilities don’t pose as direct a threat as SQL injection, some vendors tend to overlook CSRF issues.

Let’s get to the point: What is read-only CSRF? Here, I categorize the following vulnerabilities under read-only CSRF, as their exploitation techniques are fundamentally the same as CSRF:

- JSONP Hijacking  
- Flash Cross-Domain Hijacking  
- CORS Cross-Domain Resource Reading

...and so on. There’s also Silverlight cross-domain, but for this discussion, I’ll focus on the three most common types.

# Read-only CSRF

Next, I’ll analyze each of the three vulnerability cases mentioned above.

## JSONP Hijacking

### Vulnerability Case

Consider the following request:

The response contains a phone number (in my test account, the phone was not bound). If we want to retrieve this phone number via an interactive CSRF attack, how should we proceed?

Notice that this request includes a `callback` parameter, and the response resembles a JavaScript function.

The standard JavaScript function definition looks like this:

```javascript
function funName(){}
```

In this case, the response lacks the `function` keyword and the function body (curly braces), retaining only the function name and parameters. The clever among you may have realized: this is equivalent to referencing a custom function, with the parameters acting like an array. Therefore, we can first define this function in JavaScript and then reference the request—thus retrieving the data.

Now, let’s construct a PoC:

```html

<script>function jsonp2(data){alert(JSON.stringify(data));}</script>
<script src="http://gh0st.cn/user/center?callback=jsonp2"></script>
```

Let’s test this with a normal account (one that has a bound phone number):

### Case Summary

Through this example, we can see that the HTML `<script>` tag can, under certain conditions, read content across domains.

There are several ways to fix this vulnerability:

1. Obfuscate the response body content  
2. Implement restrictions using `Referer` and other headers...and so on.

## Flash Cross-Domain Hijacking

Flash cross-domain is a classic issue. When conducting web asset inventory, you may occasionally encounter a file named **crossdomain.xml**. If its content is as follows, it indicates a Flash cross-domain vulnerability—this configuration allows access from all domains:

```xml
<?xml version="1.0"?>
<cross-domain-policy>
  <allow-access-from domain="*" />
</cross-domain-policy>
```

Why is this the case? The process works like this:

Suppose gh0st.cn hosts an SWF file that attempts to retrieve userinfo from vulkey.cn. The SWF first checks whether **crossdomain.xml** exists on the vulkey.cn server. If it doesn’t, access fails. If it does exist, the SWF then checks whether the file permits access from gh0st.cn. If access is allowed, the SWF from gh0st.cn can successfully retrieve the content. Therefore, the key to enabling Flash cross-domain data transfer is the **crossdomain.xml** file.

If you find a **crossdomain.xml** file with the content shown above, a Flash cross-domain hijacking vulnerability exists.

### Vulnerability Case

During a test on a vendor’s system, I discovered such a file:

In this case, I needed to accomplish two things:

1. Find an interface that returns sensitive information  
2. Build a PoC

For the sensitive interface, I used the personal center as an example. The PoC was sourced from:https://github.com/nccgroup/CrossSiteContentHijacking/raw/master/ContentHijacking/objects/ContentHijacking.swf

### Case Summary

It’s a simple mechanism, yet highly effective. Its exploitation method is identical to CSRF—only the PoC needs adjustment.

The fix is equally straightforward: modify the `domain` attribute in `<allow-access-from domain="*" />` to restrict access appropriately.

## CORS Cross-Domain Resource Reading

### Vulnerability Case

As shown in the image above, I added the request header `Origin: http://gh0st.cn` to my request. The corresponding response included the header `Access-Control-Allow-Origin: http://gh0st.cn`, which indicates that cross-origin requests from http://gh0st.cn are permitted. Therefore, http://gh0st.cn can read content from this domain across origins. Let me briefly explain `Origin`:

`Origin` is similar to `Referer`, but it strips away all request parameters, retaining only the **triplet (protocol, host, port)**. Standard browsers include the `Origin` header in every request, especially during cross-origin operations (e.g., AJAX calls).

To test for CORS vulnerabilities, you can follow the method I demonstrated above.

How can this be exploited? I used the open-source project on GitHub: https://github.com/nccgroup/CrossSiteContentHijacking. The readme.md file provides detailed instructions, so I won’t go into them here. Once the issue is confirmed, further validation is needed.

I found an interface that returns sensitive data such as the user’s real name, ID number, and phone number:

/daren/author/query(Note: This request was captured as a POST, but without a request body. Testing showed that any content in the body is acceptable.)

Response body content:

I hosted the CrossSiteContentHijacking project locally at:  
http://127.0.0.1/CrossSiteContentHijacking/ContentHijackingLoader.html

Following the project’s instructions, I configured the parameters and clicked the "Retrieve Contents" button:

The test results confirmed that cross-origin reading is possible:

### Case Summary

This issue arises from inadequate validation of the `Origin` header. Strengthening this validation resolves the problem.

# Flowchart

```mermaid
flowchart TD 
	A[Read-only CSRF] --> B[JSONP Hijacking]
    A --> C[Flash Cross-Domain Hijacking]
    A --> D[CORS Cross-Domain Resource Reading]

B --> E[Vulnerability Case: Injecting custom function via callback parameter]
    B --> F[Case Summary: script tag allows cross-domain reading ]

C --> G[Vulnerability Case: crossdomain.xml allows all domains]
    C --> H[Case Summary: Flash cross-domain depends on crossdomain.xml]

D --> I[Vulnerability Case: Unvalidated Origin header leads to cross-domain reading of sensitive data]
    D --> J[Case Summary: Improper CORS configuration]
```

# Conclusion

There’s not much more to say at the end. I hope this summary proves helpful to everyone.

本内容由@depybot AI智能助手生成,原作者@gh0stkey,用于AI写作测试～

Comment List [Latest 5]

Comment

AI助手回复

内容添加 @depybot 可召唤AI机器人回复。此操作将自动公开评论内容,如涉及敏感信息请勿使用,如有需要请联系站长删除

© Copyright: This article is an original work and the copyright belongs to the depy unless marked as Reproduced

Please contact the blogger for authorization to reprint

读取型CSRF-需要交互的内容劫持

© Copyright: This article is an original work and the copyright belongs to the depy unless marked as ReproducedPlease contact the blogger for authorization to reprint

© Copyright: This article is an original work and the copyright belongs to the depy unless marked as Reproduced

Please contact the blogger for authorization to reprint