有哪些方法可以不使用csrf token就能防御csrf？

Question

有哪些方法可以不使用csrf token就能防御csrf？

Answer 1

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prev...

CSRF Prevention without a Synchronizer Token

CSRF can be prevented in a number of ways. Using a Synchronizer Token is one way that an application can rely upon the Same-Origin Policy to prevent CSRF by maintaining a secret token to authenticate requests. This section details other ways that an application can prevent CSRF by relying upon similar rules that CSRF exploits can never break.

Checking The Referer Header

Although it is trivial to spoof the referer header on your own browser, it is impossible to do so in a CSRF attack. Checking the referer is a commonly used method of preventing CSRF on embedded network devices because it does not require a per-user state. This makes a referer a useful method of CSRF prevention when memory is scarce. This method of CSRF mitigation is also commonly used with unauthenticated requests, such as requests made prior to establishing a session state which is required to keep track of a synchronization token.

However, checking the referer is considered to be a weaker from of CSRF protection. For example, open redirect vulnerabilities can be used to exploit GET-based requests that are protected with a referer check and some organizations or browser tools remove referrer headers as a form of data protection. There are also common implementation mistakes with referer checks. For example if the CSRF attack originates from an HTTPS domain then the referer will be omitted. In this case the lack of a referer should be considered to be an attack when the request is performing a state change. Also note that the attacker has limited influence over the referer. For example, if the victim's domain is "site.com" then an attacker have the CSRF exploit originate from "site.com.attacker.com" which may fool a broken referer check implementation. XSS can be used to bypass a referer check.

In short, referer checking is a reasonable form of CSRF intrusion detection and prevention even though it is not a complete protection. Referer checking can detect some attacks but not stop all attacks. For example, if you HTTP referrer is from a different domain and you are expecting requests from your domain only, you can safely block that request.

Checking The Origin Header

The Origin HTTP Header standard was introduced as a method of defending against CSRF and other Cross-Domain attacks. Unlike the referer, the origin will be present in HTTP request that originates from an HTTPS url.

If the origin header is present, then it should be checked for consistency.

Challenge-Response

Challenge-Response is another defense option for CSRF. The following are some examples of challenge-response options.

• CAPTCHA
• Re-Authentication (password)
• One-time Token

While challenge-response is a very strong defense to CSRF (assuming proper implementation), it does impact user experience. For applications in need of high security, tokens (transparent) and challenge-response should be used on high risk functions.

Answer 2

判断referer，

举个例子，你的支付页面是从首页跳转的，也是就是说，referer指向你的首页，那么你就可以通过检查referer是否指向你的首页来判断数据是否被csrf。

Answer 3

1、验证cookie和表单中的token。
2、验证session和表单中的token。
3、提交表单前写一个token到cookie，过期时间极短（1s、2s等）,后端检查是否有这个token。

Answer 4

防御csrf一般有三种方法：1.验证referer，referer指向的是请求源，但是一些浏览器支持修改referer，所以这个方法并不安全。2.验证token，将token放在请求头的自定义属性中，这个是目前最安全的做法了