有哪些方法可以不使用csrf token就能防御csrf？
判断referer，
举个例子，你的支付页面是从首页跳转的，也是就是说，referer指向你的首页，那么你就可以通过检查referer是否指向你的首页来判断数据是否被csrf。
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.