DEV Community

Cover image for Missed Frontend Vulnerabilities (1): CSS is not as safe as you think!

Missed Frontend Vulnerabilities (1): CSS is not as safe as you think!

Mojtaba Izadmehr on October 22, 2020

In this series of posts, I want to go through some security-related frontend issues that I find interesting. I will try to test out these ideas wit...
Collapse
 
alohci profile image
Nicholas Stimpson

This is somewhat misleading as it needs some JS support, provided by React or similar. Without it, what gets entered into the input box won't get reflected on to the value attribute, in which case none of the selectors can ever match. So it's more a vulnerability of React than it is of CSS.

Collapse
 
mizadmehr profile image
Mojtaba Izadmehr • Edited

That's indeed correct, but it is a common (not very safe) pattern, and many developers use it to save the values in an attribute.
So let's take a look at some famous cases:

  • React, many websites that use React and don't consider this.
  • Gmail: As of right now Gmail (uses data-initial-value property), so if in a hypothetical case Gmail is exposed by this simple vulnerability, it will take down all the websites which use Google OAuth with it.
  • 1Password: Another example (one of many reasons I believe products like 1password are a terrible way) is 1Password. It just conveniently adds an attribute called data-com.agilebits.onepassword.initial-value to the page with the value of your password (1password.community/discussion/713...) which is indeed a insane. It basically means that if your website is exposed to this vulnerability, and you already made sure that all password fields are secure. The password of the users who use 1Password can be stolen!
Collapse
 
csaltos profile image
Carlos Saltos

Great article !! ... I was copying every external asset locally ... fonts, CSS, Javascript, etc. ... I did not know why but I feel it is best to keep it under control ... and now ... now I know the reason thanks to you -> SECURITY !! ... this is wonderful, thanks mate for the excellent article !! 👍😎

Collapse
 
eldrimm profile image
Wesley van Drimmelen

Nice article! I just finished a small research on the same topic, so good to read yours aswell! I'd like to mention another solution: use strict CSP headers. That way you can block requests which are not allowed. Nice article, keep up te work!

Collapse
 
mizadmehr profile image
Mojtaba Izadmehr

Thanks! I didn't consider CSP while writing this, so it seems interesting.
Indeed the best way is to self-host every asset, and then use CSP to block any additional calls that you did not expect. Otherwise even if one of the CSS files is on a server they can still use this vulnerability.
I will update the article based on your suggestion:)

Collapse
 
xcs profile image
Cristian

CSP is useful, but I don't think it is for this case as the initial resource and hack are loaded from the same domain.

Wouldn't it be more useful to add an integrity check to make sure the file is not updated? Do link nodes support the integrity attribute?

Collapse
 
eldrimm profile image
Wesley van Drimmelen • Edited

Using strict CSP you can block the background-image requests, which would be the malicious domain/api of the attacker. Using strict csp directives you can block these requests, that's how we're doing it at my current job

Collapse
 
wisniewski94 profile image
Wiktor Wiśniewski

You can inspect the network tab while typing in the password field ;)

Collapse
 
mizadmehr profile image
Mojtaba Izadmehr

Indeed, but the issue is that if they use something like the dormant approach we used here, the network requests will only happen when they want it to happen.
So It is possible that you never see any network requests, but 6 months later, they can change the content of their internally @imported keylogger, and turn it on four a few hours and steal credentials of your users in that period of time. I'd say if they do this in a smart way, it is impossible for you to figure out.

Collapse
 
wisniewski94 profile image
Wiktor Wiśniewski

Popular CDNs have hashes in file names so you can't update CSS without anybody noticing it.
If you use some cheeky third parties to host your assets then well - it's your fault.

Thread Thread
 
mizadmehr profile image
Mojtaba Izadmehr

That's a good point, now I'm curious to see if there is any workaround for that one, or if there are any CSS libraries in this third parties which still uses @import. I would hope not, but I'd guess so.
If you get it from npm, then still the issue remains.

Thread Thread
 
wisniewski94 profile image
Wiktor Wiśniewski

Yes, npm is full of vulnerabilities and when you start using open source libraries you basically take that risk.

I highly recommend using snyk.io to keep an eye on your libs. It's not free. History knows a lot about people who saved a dollar on security.

Personally, I would think twice or maybe even tens of times if I had to include an o-s library in the enterprise level app. Or an app that actually makes money.

Collapse
 
vanali_marco profile image
Marco Vanali • Edited

Very interesting post, thank you! Loved it!

"" then you would have to make sure that you only allow that single file and no other endpoints from that server. ""

This could be done by adding logic in your backend I assume?
But what if they change the content of that file you are allowing?

In the end.. what is the solution to prevent this keylogging from happening? What can we do as FE dev?
Is not saving the value of the text input in an attribute a solution :)?
Thank you :)

Collapse
 
mizadmehr profile image
Mojtaba Izadmehr

You are right, First good practice is not to store the value of the password in the value property of the input. Though, some password manager extensions, store the user password in a custom property (like 1Password using data-com.agilebits.onepassword.initial-value).
The second solution is of course finding all the servers that you want to allow the client to make requests to and use Content-Security-Policy tags in your HTML tag, to only whitelist those servers.
I believe combining these two solutions can make you almost confident of your safety (you can never be too confident).

Collapse
 
brunhildevink profile image
Brunhilde

Very interesting! Who would've thought CSS can be used as a keylogger..

Collapse
 
amiralmusawi profile image
Amir Almusawi

That is really creative work.

Collapse
 
hmphu profile image
Phu Hoang

Thank you for your interesting article

Collapse
 
jkettmann profile image
Johannes Kettmann

Really interesting article and very well written. Thanks a lot

Collapse
 
hansregeer profile image
Hans Regeer

Interesting. makes sense ;)

Collapse
 
yellow1912 profile image
yellow1912

These people are so smart.

Collapse
 
futureistaken profile image
R Z

Amazing

Collapse
 
sven5 profile image
Sven Glöckner

This is really interesting and shocking at the same time. This is really a very good article, you should always keep this possibility in mind.

Collapse
 
area73 profile image
Rodrigo • Edited

It looks that it is not working :(

Collapse
 
skye profile image
Skye Wu

This is very interesting, but when repeated characters are entered, the request is sent only the first time.
This let us know that we can use the background image to record.

Collapse
 
shahinashanu profile image
shahina sheikh

Impressed..useful article 👍

Collapse
 
ghoshsanjeev profile image
Sanjeev

Hi, have you posted any other article in this series?