Two fundamental issues allowing for XSS in Ruby on Rails (RoR) applications. As RoR is just a framework, these all depend on an application using the framework in a way that exposes these vulnerabilities.
This starts off in a pretty straight-forward way with an arbitrary file upload vulnerability, but also includes a bit of discussion about exploiting it in a more hardened environment which had some interesting insight.
By hiding a cross-site-scripting attack in the profile update functionality, specifically the profile image.Judging from the payload it looks like a straight-forward unescaped input that gets reflected on profile pages, though they did need to contend with Cloudflare's WAF...
Hard-coded crednetials strike again, enabled a couple Server Side Request Forgeries as the URL to be requested was inside an encrypted, but user-provided URL parameter.Within the application there were a couple endpoints that would take a `Url` parameter...
Probably as easy of a 2FA bypass as I've seen, effectively if the account had 2FA the second stage of the password reset form would submit to `/reset2fa` and if there was no 2FA registered for the account, it would submit to `/reset` so the attack was just to modify the submission to point to `/reset` instead of `/reset2fa` and it wouldn't prompt for the 2FA token.
For some `UIBean` tags the `name` field was vulnerable to a double OGNL evaluation when there was no corresponding `value` field which could lead to remote code execution.
An uninitalized "Fast Tracker" in the Window's HTTP Protocol stack as used by IIS. Despite providing a bit of a crash analysis and a POC the post is missing information about the vulnerability as their primary focus was on building out the exploit.
Copying and pasting an HTML element with a script within it can result in an XSS in vditor text editor.This does feel like a bit of a stretch for an attack scenario, pasting in malicious content to an editor, but not really a thread situation I've thought much about either...
A bug and exploit that hearkens back to old-school browser exploitation. The bug is a use-after-free in `concat_function()` for variable concatenation, which is abused in the PHP engine to escape `disable_functions` and `open_basedir` sandboxing.
Somewhat traditional CE.TE request smuggling attack on a few of Apple's domains.The main trick with this one was to place a `\n ` in the `Transfer-Encoding` header name...
Cool little trick against the NodeBB oauth flow resulting in a CSRF that would associate an attackers third-party account with a victim NodeBB account.
The title says it all, CSRF protection was disabled for a period of time on Stripe's Dashboard.As the most sensitive actions required reentering the user's password or solving a captcha the damage was limited but you could still change various account settings...
Sometimes vulnerabilities come from trying to be too generic/handle all the possibilities, this is one of those situations.What you have the Spring Framework letting users write simple Java classes with fields, getters/setters and setting those up as models for a particular endpoint...