Last week I came across this typicalprivilege escalationvulnerability. 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 usesProjectHook.find(params[:hook_id]), so it’s not scoped to the project.
Let’s go and fix similar problems. But now forsomething completely different:
Only.37%ofthetopmillion Alexa sitesusea 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.
Thepagewe’relinkingto with target=’_blank’gainspartialaccesstothesourcepageviathewindow.openerobject.
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.
