It’s a phase 1 clinical trial designed only to assess safety and determine the appropriate dosage. Future trials will focus on efficacy.

Wouldn't platforms see the supposed XSS payloads in their logs and publish analyses of them, or at the very least, announce that they happened?

Also because nobody actively exploited them! You're using the word "detected" to mean "discovered", which nobody working in the field would ever do.

detected: WAF caught or detected the attack and raised an alert, post-exploitation

discovered: they audited or pentested themself and found out, preemptively

I just mean that Coinbase didn’t see anything happening and didn’t take action though the boy successfully exploited the vulnerability on their live system.

I'm sure they can store far more than 20 TB now, but it is true that the content pool is much larger. I would guess it's not a favorable ratio.

Thanks for making this! I've been looking for something like this for a while.

I AirDropped the PoC to my vulnerable iPhone. It didn't cause a crash until I tried to edit it in the Photos app.

I downloaded the image he provided (https://www.dpreview.com/sample-galleries/4949897610/pentax-...)

The DNG file did have the 01 byte at `2FD00` (from xxd or hexdump -C). However it didn't have a byte position `3E40B`. I tried searching and there is literally no entry at that position. I found a 02 value at 3e40 but not at 3e40b. Is this a typo?

Where did you find it to try and repro?

You need to click the link that says "RAW (33.0MB)". The filename should be "IMGP0847.DNG".

Thanks immensely. Very important detail,

Did you find a 02 at 3E40B? I found 01 at 2FD00, but there was no 3E40B byte position entry.

I did find something similar at 00003e40: 00003e40 02 00 04 00 0a 00 00 00 30 01 00 00 00 00 00 00 |........0.......|

Yes:

  dd status=none if=IMGP0847.DNG bs=1 skip=0x3e40b count=1 | xxd
  00000000: 02

Thanks! You are correct, when I did a dump with `xxd IMGP0847.DNG > output.hex` it wasn't showing up for some reason.... But your command worked (though my dd doesn't like hex values so I needed to get decimal via printf "%d\n" 0x3E40B).

Curious if you (clearly smarter than me) know why it didn't show correctly in the xxd or hexdump for the file. Would love to learn.

  xxd IMGP0847.DNG | grep 03e400:
  0003e400: ffd8 ffc3 000e 0e10 800c 5002 0011 0001  ..........P.....

Look at the byte at offset 11 (0xb), it's there.

Ohhh the b offset (11) is an offset _on that line_ (0003e400)! I got it now:D This thread taught me a great deal. Thank you, MajesticHobo2!

Maybe you need to iMessage it to someone else? Just guessing.

The problem boils down to the lack of equivalence between a site and an origin. The article explains how https://app.example.com and https://marketing.example.com may sit at very different trust levels, but are considered the same site by the browser. You don't want https://marketing.example.com to be able to make requests to https://app.example.com with your authentication cookies, but SameSite wouldn't prevent that.

This doesn't match my experience. What am I doing different?

Example I set SameSite=Strict on www.edoceo.com and then visiting app.edoceo.com the cookie is not there? They are different sites, different origins. And the cookie is set to the domain (ie: host, ie: www.edoceo.com)

For CSRF (and for SameSite), you are not looking at what cookies are sent to attacker.example.com, but what cookies are sent to target.example.com if a request is originated from attacker.example.com (or from attacker.com).

Not sure I agree with this part:

> Allow all GET, HEAD, or OPTIONS requests.

> These are safe methods, and are assumed not to change state at various layers of the stack already.

Plenty of apps violate this assumption and do allow GET requests to alter state.

IMO apps that do this have a bug, and possibly a security one. This causes issues with prefetching, bot traffic, caching, CSRF, and just plain violates HTTP standards.

One click to perform an action and store data? Have you heard of HTML forms with method="post"?

> Those methods should be treated as idempotent

Idempotency still implies it can change state on the initial call, which to me feels wrong in the context of GET/HEAD/OPTIONS.

Indeed, the correct term here is nullipotent.

Those apps are beyond helping already. They need to fix theselves.

This is on the server side, on the app. If your supposedly-safe methods aren't safe, then CSRF may not be your biggest problem.

That’s bad because visiting an evil site can easily trick your browser into performing one of those requests using your own credentials. CORS doesn’t stop the backend state effect from happening.

That's exactly why I don't agree that GETs should be broadly exempted from CSRF protections. I'm not talking about CORS at all.

> Plenty of apps violate this assumption and do allow GET requests to alter state.

Yeah, that's not a justification. From a RESTful API design perspective, this just means plenty of apps are buggy/critical design problems. A bug in a random app does not mean HTTP verb lose their semantics.

The entire WordPress ecosystem says hello

XFF handling is the bug that keeps on giving. I'd estimate I've seen incorrect parsing of it in at least half of the web applications I've audited professionally.

The funniest is when the app renders user IP addresses somewhere and you can get XSS through it.

You can use FTP and SVN.

Both of those require a server

There doesn't need to be any kind of "polyglot payload". Local network services and devices that accept only simple HTTP requests are extremely common. The request will go through and alter state, etc.; you just won't be able to read the response from the browser.

Exactly. People who are answering must not have been aware of “simple” requests not requiring preflight.