3 ms·

Could someone explain how re-directing from a subdomain (chess.com.foo.bar) somehow got past some same-origin check?

by atdt 3y ago

fnimick 3y ago
It wasn't a proper same-origin check - the server code was checking to see if the image was hosted elsewhere, and if so, it would download and self-host it. The code to check if it was on `chess.com` probably just checked to see if the domain included that string, because laziness.
semitones 3y ago
if it's happening server side they might have had a bug where they are doing naive substring comparison instead of actual domain evaluation
DistractionRect 3y ago
Clearly chess.com was using something like "starts with" to process the re-upload. Basically don't re-upload if it starts with https://chess.com https://chess.com, but filter out if it starts with https://chess.com/registration-invite https://chess.com/registration-invite Typically same origin policies are relaxed for things like images by default [0]. So they came up with a trampoline, they created a chess.com.theirDomain.tld to get past the re-upload filter, which in turn returned a redirect, which the browser followed. [0] https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy#cross-origin_network_access https://developer.mozilla.org/en-US/docs/Web/Security/Same-o...
betenoire 3y ago
it sounded server side code allow-list the source, so it was probably just doing a string prefix check. the code to make the friend relation doesn't happen in the browser
JakeSkii 3y ago
OP Here - Like the others have said, it wasn't a proper same-origin check. We'll never know for sure how it was handled beacuse it was all done server-side but I'm guessing it was something like an if in statement on the FQDN, hence why I was able to get away with pointing it to my own domain.
bmacho 3y ago
Not CORS origin check (that does not apply to links), but hand made origin check from chess.com developers.

Could someone explain how re-directing from a subdomain (chess.com.foo.bar) somehow got past some same-origin check?

by atdt 3y ago

Could someone explain how re-directing from a subdomain (chess.com.foo.bar) somehow got past some same-origin check?

It wasn't a proper same-origin check - the server code was checking to see if the image was hosted elsewhere, and if so, it would download and self-host it. The code to check if it was on `chess.com` probably just checked to see if the domain included that string, because laziness.

semitones 3y ago

if it's happening server side they might have had a bug where they are doing naive substring comparison instead of actual domain evaluation

DistractionRect 3y ago

Clearly chess.com was using something like "starts with" to process the re-upload. Basically don't re-upload if it starts with https://chess.com https://chess.com, but filter out if it starts with https://chess.com/registration-invite https://chess.com/registration-invite Typically same origin policies are relaxed for things like images by default [0]. So they came up with a trampoline, they created a chess.com.theirDomain.tld to get past the re-upload filter, which in turn returned a redirect, which the browser followed. [0] https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy#cross-origin_network_access https://developer.mozilla.org/en-US/docs/Web/Security/Same-o...

betenoire 3y ago

it sounded server side code allow-list the source, so it was probably just doing a string prefix check. the code to make the friend relation doesn't happen in the browser

JakeSkii 3y ago

OP Here - Like the others have said, it wasn't a proper same-origin check. We'll never know for sure how it was handled beacuse it was all done server-side but I'm guessing it was something like an if in statement on the FQDN, hence why I was able to get away with pointing it to my own domain.

bmacho 3y ago

Not CORS origin check (that does not apply to links), but hand made origin check from chess.com developers.