Last week I came across this typical privilege escalation vulnerability. This type of problem happened in about 30% of the Rails apps that I reviewed. It goes like this:
- 2 users have access to 2 different projects
- 1 resource in each project (web hooks in this case)
- User 1 and 2 can access /projects/1/hooks/1 and /projects/2/hooks/1 even though one of them shouldn’t
- That’s because the resource controller uses ProjectHook.find(params[:hook_id]), so it’s not scoped to the project.
Let’s go and fix similar problems. But now for something completely different:
Only .37% of the top million Alexa sites use a Content-Security-Policy. Is it time to start implementing one?
Same-site Cookies
New: Same-Site cookies are sent only when using a web app directly, not through a request from a third-party website. With them, CSRF attacks won’t be possible anymore, because a request from a different site won’t be as a signed in user anymore. This is supported in the newest Chrome and Opera versions (and was before through general browser settings).
A cheesy name for multiple vulnerabilities in the popular ImageMagick (e.g. through rmagick, paperclip): Remote Code Execution, delete and move files, SSRF, read local files.
The page we’re linking to with target=’_blank’ gains partial access to the source page via the window.opener object.
Let’s Encrypt is not beta anymore.
Like this kind of articles?
Subscribe to hear about new Rails security resources first. Only helpful articles and guides. Monthly(ish) updates, no spam.
