Timeline for What kind of attacks do Javascript WebWorkers protect against?
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 10, 2020 at 10:27 | comment | added | hiburn8 |
If you are able to get XSS in an application and can add a web worker, you have essentially created a method of persistence, so they can be quite nasty. The main issue relates to 'bypassing' same-origin-policy with CSRF HXRs. Luckily, workers are part of the Content-Security-Policy spec, so you can limit your exposure with worker-src 'self' for example. And XHR requests made from workers would also be restricted by CSP.
|
|
| Mar 17, 2017 at 10:46 | history | edited | CommunityBot |
replaced http://security.stackexchange.com/ with https://security.stackexchange.com/
|
|
| Jul 22, 2015 at 13:21 | comment | added | Steffen Ullrich | @CivvyThePandaTM: they are not wrong and you can do some limited sandboxing using WebWorkers since they don't have access to the document. But since this is more a side effect of how they work was not explicitly introduced as a security feature I would not trust it fully. | |
| Jul 22, 2015 at 11:57 | comment | added | CivvyThePandaTM | Thanks for the answer! I do know that web workers aren't designed to be a security feature, but I looked at several posts here and many people recommended using them for sandboxing. I guess that's what I get for listening to what people on the Internet say, eh? | |
| Jul 22, 2015 at 11:53 | vote | accept | CivvyThePandaTM | ||
| Jul 22, 2015 at 6:20 | history | answered | Steffen Ullrich | CC BY-SA 3.0 |