Third-party CSS is not safe to understand and use JavaScript callback functions

In recent times, there has been a lot of discussion about creating "Keylogger" (keyloggers) through CSS.

Some people call on browser makers to "fix" it. Some have studied in depth, saying it only affects websites built through the React framework and accuses React. The real problem, however, is that third-party content is "safe".

If I introduce the above code into my file, that means trust example.com. The other party may delete the resource and give me a 404, which causes the site to be incomplete, thereby destroying this trust relationship. Alternatively, they may use other unintended data to replace the kitten's image data.

However, the effect of the picture is limited to the content area of the element itself. I can explain to the user and hope that the user believe, "Here is the content from example.com, if it is wrong, it is the original site problem, is not caused by this station." However, this problem certainly does not affect the password input box and so on content.

Third-party scripting

Third-party scripts have more control over images. If I introduced the above code into my file, I gave example.com Full control of my site's permissions. The script can:

Read/modify page content. Listens for all user interactions. Run code that consumes a lot of computational resources (such as the Cryptocoin Mining program). By sending a request to the site, this can be accompanied by a user's cookie to forward the response. Read/modify local storage by stealing user's cookies and other data. ...... Can do anything the other person wants to do.

"Local storage" is very important. If the script initiates an attack through the IndexedDB or cache API, the attack may persist throughout the site even after the script is deleted.

If you introduce scripts from other sites, you must be absolutely confident in the defense of each other and each other.

If you are attacked by a malicious script, you can set the Clear-site-data header (emptying the Site data response header) to clear all the site data.

Third-party CSS

CSS is more capable of scripting than images. Like a script, it works for the entire page. It can:

Delete/Add/modify page content. Initiates a request based on the content of the page. Can respond to multiple user interactions.

Although CSS can not modify the local storage, and can not run through the CSS Cryptocoin mining program (perhaps it is possible, but I do not know), but the malicious CSS code can still cause a great loss.

Keyboard recorder

Start with the code that is attracting wide attention:

1. input[type= "Password"][value$= "P"] {
2. Background:url ('/password?p ');
3. }

Copy Code

If the value of the input box ends with P, the above code will initiate a request to/password?p. Each character can trigger this action, which can be used to get a lot of data.

By default, the browser does not store the values entered by the user in the Value property, so this attack relies on certain things that can synchronize these values, such as React.

To address this problem, React can use another way to synchronize password fields, or the browser can restrict those selectors that match the properties of the password field. However, this is only a false security. You've only solved the problem in special cases, and the rest is still the case.

If React uses the Data-value property instead, the workaround is not valid. If the Web site changes the input box to type= "text" so that users can see what they are typing, the workaround is not valid. If a Web site creates a component and exposes value as a property, the workaround is not valid.

In addition, there are a number of other CSS-based attack methods:

Content that disappears

1. Body {
2. Display:none;
3. }
5. Html::after {
6. Content: ' HTTP Server Error ';
7. }

Copy Code

The above is an extreme example, but imagine if a third party is doing this only for a small subset of users. Not only is it difficult to debug, but it also loses the trust of the user.

A more cunning way to remove the "buy" button occasionally, or rearrange the contents of a paragraph.

Add content

1. . price-value::before {
2. Content: ' 1 ';
3. }

Copy Code

Oh, the price is on the elevation.

Move content

1. . Delete-everything-button {
2. opacity:0;
3. Position:absolute;
4. top:500px;
5. left:300px;
6. }

Copy Code

The buttons above can do important things, set them to be invisible, and place them where the user might click.

Fortunately, if the button's operation is really important, the site may display a confirmation dialog box first. But it is also not to be bypassed, just use more CSS to trick the user into clicking the "OK" button instead of "Cancel" button.

Suppose the browser does take the above workaround to solve the "keyloggers" problem. The attacker simply finds a non-password text input box (perhaps a search input box) on the page and covers it on the Password entry box. Then their attack will be available again.

Read properties

In fact, you need to worry more than just the Password entry box. You may have other hidden content stored in the attribute:

1. <input type= "hidden" name= "csrf" value= "1687594325" >
3. <iframe src= "//cool-maps-service/show?st-pancras-london" ></iframe>
5. <div></div>

Copy Code

All of this can be obtained through the CSS selector and can make a request.

Listener interaction

1. . login-button:hover {
2. Background:url ('/login-button-hover ');
3. }
5. . login-button:active {
6. Background:url ('/login-button-active ');
7. }

Copy Code

Hover and active states can be sent to the server. With the right CSS, you can get the user intent.

Reading text

1. @font-face {
2. Font-family:blah;
3. Src:url ('/page-contains-q ') format (' Woff ');
4. unicode-range:u+85;
5. }
7. HTML {
8. Font-family:blah, Sans-serif;
9. }

Copy Code

In this case, if there is a Q character in the page, the request is sent. You can create a large number of different fonts for different characters and for specific elements. Fonts can also contain ligature (ligatures), so you can begin to detect character sequences. You can even infer content by combining font techniques with scroll bar detection.

About Ligature (ligatures), you can view Wikipedia typographic ligature

Third party content is not secure

These are just some of the techniques I know, and I believe there are more.

Third-party content has strong capabilities within its sandbox area. A picture or sandboxed iframe is only in a small sandbox, but scripts and styles are scoped to your page, or even the entire site.

If you're concerned that a malicious user has tricked your site into loading third-party resources, you can use CSPs as a defense to restrict the loading of pictures, scripts, and styles to the source.

You can also use Subresource Integrity (Child resource integrity) to ensure that the script/style content matches a specific hash, otherwise it will not load. Thanks to Hacker news piskvorrr remind me!

If you would like to learn more about the hack techniques described above, including the scroll bar tips, see Mathias bynens ' talk from 2014,mike West's talk from 2013, or Mario Heiderich et al. ' s Paper from (PDF). Yes, it's not something new.

Original address, translation: translations, translation address link description,

Third-party CSS is not safe to understand and use JavaScript callback functions