Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide more relevant feedback #56

Closed
matthieusieben opened this issue Sep 14, 2015 · 7 comments
Closed

Provide more relevant feedback #56

matthieusieben opened this issue Sep 14, 2015 · 7 comments
Assignees
Labels
feature New functionality or improvement
Milestone

Comments

@matthieusieben
Copy link

It would be nice if a message was provided to the Boom.forbidden. In big applications, where Boom is used everywhere, it may not be trivial to detect where the error was generated.

@stongo
Copy link
Contributor

stongo commented Sep 14, 2015

@matthieusieben this is a touchy issue for a security related module, as giving a detailed forbidden message essentially leaks data to potential attackers

that being said, I could investigate writing a server side log message to make debugging easier

@matthieusieben
Copy link
Author

Some people argue that "Security through obscurity is not security". In the present case, it is obvious to an attacker that a csrf token has to be provided (crumb sets a cookie...) and as easy to detect that the cookie/header may be missing from the request. It would be also possible to determine that the request was rejected in an early stage of its processing by a statistical analysis of the response time...

Anyways, having a server side log message that displays exactly why the csrf did not pass would be good enough imo (and could also facilitate the detection of attacks). If you choose to do this, make sure that you print a different message when the cookie is missing and than when the one present does not match the token in the headers.

@stongo
Copy link
Contributor

stongo commented Sep 14, 2015

Ok adding the server side logging right now with a 'logUnauthorized' option to trigger it. Also good point on this being handy for monitoring

@steevhise
Copy link

Did this "logUnauthorized" ever get committed and released? Doesn't look like it, it's not in the docs, and as I'm running Crumb 6.0.3 and get an error when I try including that option in the plugin registration.
It would be useful because I'm suddenly seeing crumb not working any more, possibly due to some issue with latest hapi version.

@jonathansamines jonathansamines added feature New functionality or improvement request labels Nov 30, 2017
@spanditcaa
Copy link
Contributor

spanditcaa commented Apr 5, 2018

@jonathansamines you'll find #112 and #113 which add the logUnauthorized capability in master for hapi 17, and I pushed a 6.x.x branch for those still on hapi 16.

geek added a commit that referenced this issue Apr 23, 2018
Logunauthorized to 6.x.x - addresses #56
geek added a commit that referenced this issue Apr 23, 2018
adds logUnauthorized option - addresses #56
@geek geek added this to the 7.1.0 milestone Apr 23, 2018
@geek geek removed the request label Apr 23, 2018
@geek geek self-assigned this Apr 23, 2018
@geek
Copy link
Member

geek commented Apr 23, 2018

Fixed by #112

@geek geek closed this as completed Apr 23, 2018
@lock
Copy link

lock bot commented Jan 9, 2020

This thread has been automatically locked due to inactivity. Please open a new issue for related bugs or questions following the new issue template instructions.

@lock lock bot locked as resolved and limited conversation to collaborators Jan 9, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
feature New functionality or improvement
Projects
None yet
Development

No branches or pull requests

6 participants