I have read through the definition of Double Submit Cookie: https://github.com/OWASP/CheatSheetSeries/blob/5a1044e38778b42a19c6adbb4dfef7a0fb071099/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.md#double-submit-cookie
> the CSRF plugin sets a cookie to the client in each request, which contains the encrypted csrf token, and the client sets it on the request header in subsequent requests The OWASP guide has listed some drawbacks of csrf token without encryption. The proposal mentions that the client will set the encrypted csrf token in subsequent requests, then there will be two questions: 1. how to let the client know & set the token? 2. what token does the client set? It can't just echo back the encrypted csrf token Baoyuan <[email protected]> 于2021年11月9日周二 下午9:36写道： > > Hi Community, I have an idea to design a CSRF plugin for APISIX, the > purpose is to avoid the danger of routing attacks from CSRF. > > Taking into account the stateless nature of APISIX, I plan to use Double > Submit Cookie to verify CSRF attacks. > > Simply put, the CSRF plugin sets a cookie to the client in each request, > which contains the encrypted csrf token, and the client sets it on the > request header in subsequent requests. CSRF plugin compares and verifies > the request header with the cookie to prevent CSRF attacks. > > The CSRF plugin has two configuration items: key and expires. The key > requires the user to provide a secret key, and the plugin will generate an > encrypted cookie based on HMAC the token with this secret key. The expires > refers to the cookie expiration time, this is an option, if the user does > not provide, the plugin will provide an appropriate default value. > > The plugin works at the route level. Users can turn on the plugin on the > desired route to avoid CSRF attacks on the route as much as possible. > > Any ideas or suggestions for these? > > > Best Regards! > > Yuan Bao<[email protected]>
