4 ms·
For levels 4, 5, 6, the Sinatra configuration used client-side cookies for session and the session secret is exposed in the error page. Crashing the app and inj
by lmz 14y ago
For levels 4, 5, 6, the Sinatra configuration used client-side cookies for session and the session secret is exposed in the error page. Crashing the app and injecting custom values into the session cookie was how I got through all 3 of them. I did feel like I'm missing the point of the challenge somehow.
- benmanns 14y agoNice! I don't think this is how you were supposed to do it, but you could submit this as a bug to the Stripe team, or even suggest it as a new level for the next CTF.
- Bootvis 14y agoThey know and they already fixed it.
- foobarqux 14y agoCan you elaborate on injecting session cookies? If the secret was in the error page why did you need to do anything besides crash the app?
- lmz 14y agoThe secret is used to create a valid cookie with the required values in the session e.g. User = karma_fountain. After setting the cookie, I can use the browser to transfer karma to my account, since the browser will be logged on as karma_fountain.
- tlrobinson 14y agoThe "secret" exposed in the exception page wasn't the actual flag, it was the secret used to sign session cookies. Once you had it you could modify your session cookie (typically to pose as a different user) and re-sign the cookie with the secret.
- tlrobinson 14y agoThis is what I did for level 5 without realizing it wasn't the intended solution. I actually feel like it was a more difficult and relevant to real world attacks than the actual solution.
- meritt 14y agoSo between Sinatra's default error message giving away sensitive information and the suggested "params[..]" approach gets ALL input variables, regardless POST or GET. What other gotchas should be know about Sinatra development?
- streptomycin 14y agoBasically every framework has a development mode that gives very descriptive error messages, and you're always supposed to disable it in production.