4 ms·

This is a tragically insecure site already; the only thing keeping JS injection at bay is apparently regex matching for `script` in the id-verify page. Note: i

This is a tragically insecure site already; the only thing keeping JS injection at bay is apparently regex matching for `script` in the id-verify page. Note: it does not filter for SCRIPT. e.g.: https://alwaysonssl.com/id-verify/%3Ch1%3E%27%27%3B%21--%22%3CSCRIPT%3Ealert(%22lol%20what%22);%3C/SCRIPT%3E%3D%26%7B%28%29%7D https://alwaysonssl.com/id-verify/%3Ch1%3E%27%27%3B%21--%22%...

mholt 9y ago
Dangit, Chrome is keeping me too safe: > This page isn’t working > Chrome detected unusual code on this page and blocked it to protect your personal information (for example, passwords, phone numbers, and credit cards). > Try visiting the site's homepage. > ERR_BLOCKED_BY_XSS_AUDITOR EDIT: Firefox let me load it fine. Turns out their CSP at least prevents execution of that snippet. Smart.
- packetized 9y ago
  Precisely. This should not be a thing that can happen on a page that allows one to request and receive certificates rooted in trust stores.
GlitchMr 9y ago
Content security policy seems to block this for me, so at least there is that. Content-Security-Policy: default-src 'self'; script-src 'self' platform.twitter.com syndication.twitter.com gitcdn.github.io code.jquery.com maxcdn.bootstrapcdn.com cdnjs.cloudflare.com dcggld9bcojs3.cloudfront.net; img-src data: 'self' dcggld9bcojs3.cloudfront.net; style-src 'self' 'unsafe-inline' gitcdn.github.io maxcdn.bootstrapcdn.com cdnjs.cloudflare.com; font-src 'self' data: ; form-action 'self'; child-src 'self' platform.twitter.com; connect-src 'self' syndication.twitter.com; I'm not entirely sure why gitcdn.github.io is on list of allowed script paths, but at least XSS injection is not straightforward, to run scripts, you need to hijack one of those hosts. --- As for insecure claim, it does have an XSS attack, but Content-Security-Policy reduces its impact to minimum. You cannot make do a request to an arbitrary domain by loading an external resource. So even if one part is insecure, the other one prevents an attack - security in depth. Of course, they still should fix that XSS attack. I also decided to check if they don't sign certificates for domains that disallow this (by means of CAA DNS record). They properly do, as SSL baseline requirements say, so nothing to report.
- lol768 9y ago
  Whitelisting entire CDNs like that is incredibly dangerous, see https://github.com/cure53/XSSChallengeWiki/wiki/H5SC-Minichallenge-3:-%22Sh*t,-it%27s-CSP!%22 https://github.com/cure53/XSSChallengeWiki/wiki/H5SC-Minicha...
  - GlitchMr 9y ago
    Oh, you are correct. This will only delay an attack. There is however some sort of firewall preventing using `<script>` tag.
- chrismorgan 9y ago
  > You cannot make do a request to an arbitrary domain by loading an external resource. Not true; thanks to style-src 'unsafe-inline', <style>:root{background-image:url(https://example.com/)}</style> https://example.com/)}</style> will work just fine.
chrismorgan 9y ago
They didn’t do a good job with protecting against injection, but at least they have a generally decent CSP, which stops inline JavaScript. However, the CSP does include style-src 'unsafe-inline', so you can basically just hide all of their content and put just about whatever you like on the page, but not actually execute anything directly: https://alwaysonssl.com/id-verify/%3Cstyle%3Emain,.jumbotron%7Bdisplay:none%7D%3C/style%3E%3C/main%3E%3Ca%20href=http://example.com%3EClick%20this%20link%20to%20continue.%3C/a%3E https://alwaysonssl.com/id-verify/%3Cstyle%3Emain,.jumbotron... Or even use a meta refresh to make it redirect to somewhere you control: https://alwaysonssl.com/id-verify/%3Cstyle%3Emain%7Bdisplay:none%7D%3C/style%3E%3Cmeta%20http-equiv=%22refresh%22%20content=%220;%20url=http://example.com/%22%3E https://alwaysonssl.com/id-verify/%3Cstyle%3Emain%7Bdisplay:...

mholt 9y ago

Dangit, Chrome is keeping me too safe: > This page isn’t working > Chrome detected unusual code on this page and blocked it to protect your personal information (for example, passwords, phone numbers, and credit cards). > Try visiting the site's homepage. > ERR_BLOCKED_BY_XSS_AUDITOR EDIT: Firefox let me load it fine. Turns out their CSP at least prevents execution of that snippet. Smart.

packetized 9y ago
Precisely. This should not be a thing that can happen on a page that allows one to request and receive certificates rooted in trust stores.

GlitchMr 9y ago

Content security policy seems to block this for me, so at least there is that. Content-Security-Policy: default-src 'self'; script-src 'self' platform.twitter.com syndication.twitter.com gitcdn.github.io code.jquery.com maxcdn.bootstrapcdn.com cdnjs.cloudflare.com dcggld9bcojs3.cloudfront.net; img-src data: 'self' dcggld9bcojs3.cloudfront.net; style-src 'self' 'unsafe-inline' gitcdn.github.io maxcdn.bootstrapcdn.com cdnjs.cloudflare.com; font-src 'self' data: ; form-action 'self'; child-src 'self' platform.twitter.com; connect-src 'self' syndication.twitter.com; I'm not entirely sure why gitcdn.github.io is on list of allowed script paths, but at least XSS injection is not straightforward, to run scripts, you need to hijack one of those hosts. --- As for insecure claim, it does have an XSS attack, but Content-Security-Policy reduces its impact to minimum. You cannot make do a request to an arbitrary domain by loading an external resource. So even if one part is insecure, the other one prevents an attack - security in depth. Of course, they still should fix that XSS attack. I also decided to check if they don't sign certificates for domains that disallow this (by means of CAA DNS record). They properly do, as SSL baseline requirements say, so nothing to report.

lol768 9y ago
Whitelisting entire CDNs like that is incredibly dangerous, see https://github.com/cure53/XSSChallengeWiki/wiki/H5SC-Minichallenge-3:-%22Sh*t,-it%27s-CSP!%22 https://github.com/cure53/XSSChallengeWiki/wiki/H5SC-Minicha...
- GlitchMr 9y ago
  Oh, you are correct. This will only delay an attack. There is however some sort of firewall preventing using `<script>` tag.
chrismorgan 9y ago
> You cannot make do a request to an arbitrary domain by loading an external resource. Not true; thanks to style-src 'unsafe-inline', <style>:root{background-image:url(https://example.com/)}</style> https://example.com/)}</style> will work just fine.

chrismorgan 9y ago

They didn’t do a good job with protecting against injection, but at least they have a generally decent CSP, which stops inline JavaScript. However, the CSP does include style-src 'unsafe-inline', so you can basically just hide all of their content and put just about whatever you like on the page, but not actually execute anything directly: https://alwaysonssl.com/id-verify/%3Cstyle%3Emain,.jumbotron%7Bdisplay:none%7D%3C/style%3E%3C/main%3E%3Ca%20href=http://example.com%3EClick%20this%20link%20to%20continue.%3C/a%3E https://alwaysonssl.com/id-verify/%3Cstyle%3Emain,.jumbotron... Or even use a meta refresh to make it redirect to somewhere you control: https://alwaysonssl.com/id-verify/%3Cstyle%3Emain%7Bdisplay:none%7D%3C/style%3E%3Cmeta%20http-equiv=%22refresh%22%20content=%220;%20url=http://example.com/%22%3E https://alwaysonssl.com/id-verify/%3Cstyle%3Emain%7Bdisplay:...