is CSRF implemented out of the box? #108
Comments
|
It's no provided yet but it on my TODO list to provide automatic anti-CSRF features - we can use this issue to track progess. |
|
@bobf how are you planning to implement it?
|
|
@bobf I want to make a PR adding an auto generated csrf_token to session on init or reset |
Add to middleware in app's `src/main.zig`:
```zig
pub const jetzig_options = struct {
pub const middleware: []const type = &.{
jetzig.middleware.AntiCsrfMiddleware,
};
};
```
CSRF token available in Zmpl templates:
```
{{context.authenticityToken()}}
```
or render a hidden form element:
```
{{context.authenticityFormElement()}}
```
The following HTML requests are rejected (403 Forbidden) if the
submitted query param does not match the value stored in the encrypted
session (added automatically when the token is generated for a template
value):
* POST
* PUT
* PATCH
* DELETE
JSON requests are not impacted - users should either disable JSON
endpoints or implement a different authentication method to protect
them.
|
@IbrahimOuhamou See this PR: #120 Example usage here: https://github.com/jetzig-framework/jetzig/pull/120/files#diff-f8a5de4287a4ded16bbe3960bb42dce20868f59ee482a7665a914e1608d81da6R2 I need to do a bit of work to figure out how to test this functionality and I need to review it so I won't be merging tonight, but it should be ready for use by the weekend. |
|
I see that you used the session for the token, why didn't you stick to the cookie? wouldn't it be faster than session decryption? |
|
@bobf when you are done tell me so I can close the issue (I got notification that for the pr) |
|
@IbrahimOuhamou No problem. I've decided to go back to using the session for these reasons:
I am not an expert in this stuff so if you have any feedback on this I would be happy to hear it. |
Add to middleware in app's `src/main.zig`:
```zig
pub const jetzig_options = struct {
pub const middleware: []const type = &.{
jetzig.middleware.AntiCsrfMiddleware,
};
};
```
CSRF token available in Zmpl templates:
```
{{context.authenticityToken()}}
```
or render a hidden form element:
```
{{context.authenticityFormElement()}}
```
The following HTML requests are rejected (403 Forbidden) if the
submitted query param does not match the value stored in the encrypted
session (added automatically when the token is generated for a template
value):
* POST
* PUT
* PATCH
* DELETE
JSON requests are not impacted - users should either disable JSON
endpoints or implement a different authentication method to protect
them.
Add to middleware in app's `src/main.zig`:
```zig
pub const jetzig_options = struct {
pub const middleware: []const type = &.{
jetzig.middleware.AntiCsrfMiddleware,
};
};
```
CSRF token available in Zmpl templates:
```
{{context.authenticityToken()}}
```
or render a hidden form element:
```
{{context.authenticityFormElement()}}
```
The following HTML requests are rejected (403 Forbidden) if the
submitted query param does not match the value stored in the encrypted
session (added automatically when the token is generated for a template
value):
* POST
* PUT
* PATCH
* DELETE
JSON requests are not impacted - users should either disable JSON
endpoints or implement a different authentication method to protect
them.
Add to middleware in app's `src/main.zig`:
```zig
pub const jetzig_options = struct {
pub const middleware: []const type = &.{
jetzig.middleware.AntiCsrfMiddleware,
};
};
```
CSRF token available in Zmpl templates:
```
{{context.authenticityToken()}}
```
or render a hidden form element:
```
{{context.authenticityFormElement()}}
```
The following HTML requests are rejected (403 Forbidden) if the
submitted query param does not match the value stored in the encrypted
session (added automatically when the token is generated for a template
value):
* POST
* PUT
* PATCH
* DELETE
JSON requests are not impacted - users should either disable JSON
endpoints or implement a different authentication method to protect
them.
|
@bobf I think django uses cookies and I that it would be faster |
|
@IbrahimOuhamou Django uses cookies but it also cryptographically signs the token and verifies its authenticity, so it is not as simple as comparing the bytes in the token. Ref here: By using the session we achieve same result. We can look at optimising later by storing a separate, signed cookie and using a faster algorithm than the session encryption, but I think that the performance would be quite negligible. I will do some benchmarking to compare once I find time to do that optimisation. Also bear in mind that the performance hit will only impact pages that call |
|
I have merged the PR - let me know if you hit any issues. |
I don't know how it should be implemented, but I guess we can do a
try session.put("csrf", csrf)on session init, or it can be implemented by the userThe text was updated successfully, but these errors were encountered: