Securitum's security research team publishes web vulnerability write-ups on XSS, DOMPurify bypasses, prototype pollution, and CSS data exfiltration.
Commenters cite its write-ups as concrete examples of HTML sanitizer failures and CSS-based data theft, as well as the fail2ban remote code execution bug.
Yes, because it is worth in pentesting services 180k USD, no more no less. I mean, you can pay around 360k in London or SV rates and 180k in European for _similar_ skills people.
Calc based on 3 months, 5 people, 600USD/md rate.
EDIT as I can't reply to tpaceck below: no, those 2000usd/day rates do not exists in projects in size of 300MD like here. In general they do not exist for big projects.
Yes, I agree, you have rates around 1200 in high cost countries, yet as I wrote earlier, you can have similar/the same skill level at 600 usd/md if you're willing to work with guys not from HCC.
As to the skills I'm talking this level: https://research.securitum.com/mutation-xss-via-mathml-mutation-dompurify-2-0-17-bypass/
I had to look up what prototype pollution is. This post has a good explanation [1].
The attacker construct an object on your server which contains an own-property '__proto__'. This is straightforward to do if you decode user-supplied JSON (e.g. a REST API) but this alone is not a vulnerability.
The vulnerability occurs when you iterate over this object's own-properties and use the resulting keys on another object. If the attacker can arrange for `obj2[key].value =...`, where 'key' is taken from the first object, then they have modified Object.prototype, which affects all other objects.
1: https://research.securitum.com/prototype-pollution-and-bypassing-client-side-html-sanitizers/
<portal> is an experiment/pet project pushed (and only implemented!) by one browser vendor, which as far as I know remains feature flagged.
It was shipped behind a flag with an initial implementation vulnerable to a same origin policy bypass as well as local file disclosure. As far as I can tell the only reason it wasn't assigned a Moz standards position of "harmful" is because Google argued "it's actually still a work in progress!" (three years ago).
Refs:
- https://research.securitum.com/security-analysis-of-portal-element/
- https://github.com/mozilla/standards-positions/issues/157
Remember when fail2ban had an RCE to execute things on a server via root user and it was as simple as parsing an email string because it was executing the mail binary on the other end? [1]
That's pretty much the reason why I started to write my own guard tools.
I don't need people from China or Russia logging in to my server. I don't understand why tools like this are never built in an ASN aware manner, blocking mechanisms would be so much easier.
[1] https://research.securitum.com/fail2ban-remote-code-execution/
My favorite example of the technical failings of HTML: https://research.securitum.com/mutation-xss-via-mathml-mutation-dompurify-2-0-17-bypass/ is a HTML sanitizing vulnerability that came about because some HTML not only doesn't survive a parse-stringify cycle, but the generated DOM tree does not survive a stringify-parse cycle!
Because DOMPurify is not perfect. Due to some problem of HTML parsing, there were some ways to bypass it: https://research.securitum.com/mutation-xss-via-mathml-mutation-dompurify-2-0-17-bypass/
Having a builtin XSS sanatizer means it could always use a single parser to prevent such bypass.