4 ms·

Well, I haven't analysed the exact technical reason for why submitting the order failed. But I'm pretty certain that submitting a HTML form is a solved problem

Well, I haven't analysed the exact technical reason for why submitting the order failed. But I'm pretty certain that submitting a HTML form is a solved problem in web development.. Or at least it should be. I haven't tried submitting a form with an async fetch from a web worker that communicates with a redux store implemented in WebAssembly yet (or whatever that web app is doing..).

SahAssar 7y ago
If the order site is just submitting an HTML form in the old way with credentials stored in a cookie (also the old way) that would probably be open to trivial CSRF attacks. If it is somehow checking for support for SameSite, Secure, CSP or any of the other mechanisms that have been implemented in the last years then it might fail. Or they might be using mechanisms that work around the problem that those three are supposed to help since they are not available in older clients, but just don't have the resources to test the random android 4.12 version that you use. I think it should have a proper error message if that is the case. But I feel like you are pointing the finger in the wrong direction. I try to build my apps without extraneous fads, but keeping a webapp secure (in other words keeping up to date with the latest protections) does not mean "submitting a form", and it does not mean letting any old client lacking the required protections through. It also does not mean doing "WASM compiled redux reducers in ES6 module workers authenticating over JWT to send gRPC commands to a kafka broker talking with ingressrouting over anycast and a internal service mesh with mTLS3.9 auth using curve9999.9, token binding and Wireguard to secure internal communications over a VPC-less multi-cloud k8s cluster that uses Multi-Raft, Single-Paxos to have a single, distributed, disputably non-consistent CRDT-consensus algo over blockchain RS-232". So, yeah, I'm not for fads over usability in tech. But I'm also not for supporting insecure clients just because the manufacturer of those clients doesn't give a shit.
- tedivm 7y ago
  CSRF doesn't require any javascript to defend against. Having a nonce inside of the HTML resolves that completely. SameSite and Secure cookies also don't require any javascript, just some extra HTTP headers. I don't think security justifies this.

SahAssar 7y ago

If the order site is just submitting an HTML form in the old way with credentials stored in a cookie (also the old way) that would probably be open to trivial CSRF attacks. If it is somehow checking for support for SameSite, Secure, CSP or any of the other mechanisms that have been implemented in the last years then it might fail. Or they might be using mechanisms that work around the problem that those three are supposed to help since they are not available in older clients, but just don't have the resources to test the random android 4.12 version that you use. I think it should have a proper error message if that is the case. But I feel like you are pointing the finger in the wrong direction. I try to build my apps without extraneous fads, but keeping a webapp secure (in other words keeping up to date with the latest protections) does not mean "submitting a form", and it does not mean letting any old client lacking the required protections through. It also does not mean doing "WASM compiled redux reducers in ES6 module workers authenticating over JWT to send gRPC commands to a kafka broker talking with ingressrouting over anycast and a internal service mesh with mTLS3.9 auth using curve9999.9, token binding and Wireguard to secure internal communications over a VPC-less multi-cloud k8s cluster that uses Multi-Raft, Single-Paxos to have a single, distributed, disputably non-consistent CRDT-consensus algo over blockchain RS-232". So, yeah, I'm not for fads over usability in tech. But I'm also not for supporting insecure clients just because the manufacturer of those clients doesn't give a shit.

tedivm 7y ago
CSRF doesn't require any javascript to defend against. Having a nonce inside of the HTML resolves that completely. SameSite and Secure cookies also don't require any javascript, just some extra HTTP headers. I don't think security justifies this.