You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Once you've done that, login to Dingo so you have an active session associated with your User ID. Once you've done that, you're all done on the Dingo side of things for now. Next, create a new file and run the following code:
Start that server, and visit http://localhost:3000. There, you'll see a SHA that probably looks something like a9a596375f3313c1649edf3db2f9845fc0874056. Copy that SHA, open a new Incognito window and visit your Dingo blog again. Try to visit the /admin route. You'll be redirected to the /# route of course, since you're not logged in, but we're not done yet! Open the dev tools console and run:
document.cookie="token-user=1; path=/";// Swap out the <SHA> here with the SHA you copied earlierdocument.cookie="token-value=<SHA>; path=/";
After you run that, try to access /admin again. If you did everything right, you'll be logged in as that user!
To address this, I think we should just work on implementing secure cookies and sessions in Golf itself. We could work on dinever/golf#12, and borrow the secure session and cookie logic from gorilla/sessions, since their implementation is rock-solid and secure.
It should also be noted that it's fairly hard to attack this as-is, since you'd need to know a lot about the user, and be able to figure out the time the user's token was created. That stuff is susceptible to brute-force attacks though, and since Golf and Dingo perform so well, you could try a lot of different times per second using the API.
The text was updated successfully, but these errors were encountered:
This is set-cookie issue and it can be still protected by simply setting "http-only" cookie along with "host-only" . With http , hacker can not set and use cookie with just javascript.
Steps to reproduce:
1
exists)app/model/token.go
, change theNewToken
function so it uses a set time (this is just to make it easier to reproduce this bug)Once you've done that, login to Dingo so you have an active session associated with your User ID. Once you've done that, you're all done on the Dingo side of things for now. Next, create a new file and run the following code:
Start that server, and visit http://localhost:3000. There, you'll see a SHA that probably looks something like
a9a596375f3313c1649edf3db2f9845fc0874056
. Copy that SHA, open a new Incognito window and visit your Dingo blog again. Try to visit the/admin
route. You'll be redirected to the/#
route of course, since you're not logged in, but we're not done yet! Open the dev tools console and run:After you run that, try to access
/admin
again. If you did everything right, you'll be logged in as that user!To address this, I think we should just work on implementing secure cookies and sessions in Golf itself. We could work on dinever/golf#12, and borrow the secure session and cookie logic from gorilla/sessions, since their implementation is rock-solid and secure.
It should also be noted that it's fairly hard to attack this as-is, since you'd need to know a lot about the user, and be able to figure out the time the user's token was created. That stuff is susceptible to brute-force attacks though, and since Golf and Dingo perform so well, you could try a lot of different times per second using the API.
The text was updated successfully, but these errors were encountered: