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...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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:
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.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!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 !! 👍😎
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!
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:)
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?
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
You can inspect the network tab while typing in the password field ;)
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
@import
ed 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.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.
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.
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.
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 :)
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 usingdata-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).
Very interesting! Who would've thought CSS can be used as a keylogger..
That is really creative work.
Thank you for your interesting article
Really interesting article and very well written. Thanks a lot
Interesting. makes sense ;)
These people are so smart.
Amazing
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.
It looks that it is not working :(
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.
Impressed..useful article 👍
Hi, have you posted any other article in this series?