pillarjs / csrf Goto Github PK

Hi,

as reported for session middleware:
expressjs/session#49

Could you please consider to use another module instead of uid2 ?

In that issue I suggested node-uuid, but rand-token is now used. Could you please consider to make same change here?

L.

Hello,

We use this module in our code.
According to what we see, you use Math.random() which does not produce cryptographically safe random numbers.
Is it possible to switch to some strong RNG, like "crypto.randomBytes" for example?

Thank you and Best Regards,
Zvi

If we change this to basically a class, theoretically if we just attached the tokenize function to the prototype, people could overwrite the function on instances themselves or even subclass this.

Thoughts, @jonathanong ? Are there people even using the tokenize option?

I am looking forward to a release, which includes 43f660a

Don't you think, one should attach a domain to token creation, which means if token is received from a different domain it will be discarded.

Example

tokens.create(secret, domain)
tokens.verify(secret, token, domain)

Here's why

First i agree, it is not this module problem to deal with sessions or cookies. But as a general approach i will do following with this module.

1. Create a token and set it under input field.
2. Save secret under session or cookie.
3. Check token with session using verify method.

Now the problem is, anyone can quickly grab this token by visiting a webpage on my website. Also they can copy the session from the network tab.

After this all one need to do is make CURL request by setting above values and VOILA csrf has been compromised.

If I understand correctly:

1. We should refresh token on every request and every page to mitigate BREACH (if we only refresh page with form, attacker can still guess content by repeatedly visit page without such protection)
2. Secret is per-user and if we store it on server session store, we can reuse it for a longtime, maybe a year, forever?

That's how koa-csrf appear to be using it.

I know create token is fast, only concern I have is refreshing token cause Set-Cookie every time, seem to be less than performant, any alternative available if I am to write my own csrf middleware?

I was looking through the code to understand the security model and noticed that the CSRF is being hashed with SHA-1. There's a lot of talk about replacing SHA-1 with harder to break hashing function (eg. SHA-256) in other areas so it worried me at first to see SHA-1 used to protect CSRFs. But then I got to thinking about it more... why are we hashing the CSRF? AFAIK the CSRF (even in plaintext) is not enough for a malicious agent to generate the cookie that they would need to steal a session.

What threat does hashing the CSRF token secure against as opposed to storing the CSRF in plain text in both the browser javascript and the cookie? And if the hashing is important to security of CSRFs should we be migrating CSRF to SHA-256?