Vulnerabilities tagged "web"

URL validation vulnerabilities leading to server side request forgery (SSRF) on an internal Google endpoint. The original whitelist bypass was to use a `\@` in the domain:

Missing, or maybe insufficient authentication checks on the `/users/create_admin` endpoint allowed any user (even one not logged in) to create a new administrative account and gain full admin privileged within the Stocky app.

It was possible to forge JWT tokens due to an unchecked constraint when processing the JWT before verifying. In one function the token would be "processed" as in it would pull out the relative information, passing it into `Util:verify_token(token, secret, acceptedIssuers)`

Prototype pollution through a Mermaid diagram embedded in markdown leading to stored XSS.

Weak randomness leading to a predictable filename enabling code execution...

Root issue is that WebKit violates the specification for Content-Security-Policy (CSP) violation reports, leaking the destination of a violating redirect rather than the origin in the `documentURI` field of the report.

Even if a Shopify blog was private and required a password the post titles and preview of content would be published in the globally accessible atom feed

Great little bug taking advantage of the ability to manage GSuite users directly from within `domains.google.com` by trusted the Gsuite organization name and ID from the user request. By changing out the organization's domain and id (does require knowing the target organization numeric id) in the requests `domains.google.com` makes when adding a new user, the user will be added to the new domain rather than to the one you actually own.

StreamLabs would normally only redirect to a set of whitelisted domains approved to recieve the `access_token`.The author here put some effort into discovering what domains were approved, and found `http://dragynslair.live` was whitelisted, but no longer registered...

**Vulnerability**