Why do you need to specify the encoding on each page to avoid XSS, if an attacker can still change it?

S

sorry_i_noob2018-08-07 07:58:16

XSS

sorry_i_noob, 2018-08-07 07:58:16

Hello. I read an article on Habré on protecting a PHP site from XSS: https://habr.com/company/pentestit/blog/211494/ .
The third paragraph of this article reads as follows:

3. Specify the encoding on each web page.

I have a question - what is it for? If still, an attacker can change the headers when sending their XSS to the server.
I can't understand at all how XSS works with encoding change. What did the author mean by this phrase?

If the tag is located before the tag and is filled with user data

Reply

Answer the question

In order to leave comments, you need to log in

2 answer(s)

M

Mercury13, 2018-08-07
@sorry_i_noob

The advice is somewhat outdated, and that's what it's for.
There is a frankly strange encoding called UTF-7 that was used in black for XSS. For example:
The hacker's task was to make the browser believe that the text is in UTF-7 before the encoding marker comes in the HTML.
IE11 supported UTF-7, whether Edge supports it is not in the know. The rest of the browsers gave up ten years ago.
More details:
https://nedbatchelder.com/blog/200704/xss_with_utf...
Well, it will be simply ugly if user data appears before the encoding marker and the browser incorrectly recognized this encoding. But at least XSS will not be in any encoding based on ASCII.

J

JunDevTest, 2018-08-07
@JunDevTest

XSS is exploitation of vulnerabilities in HTML, JS and other scripts.
3. Specify the encoding on each web page.
The encoding must be specified, as some browsers may incorrectly determine it and the text content on the site will become unreadable.
If the tag is located before the tag and is filled with user data
You need to filter user data, including when it is embedded in HTML markup.
For example, you allow users to change the background picture on their profile.
You have a text field where the user enters a link to an image. After that, you substitute the user's picture, for example from the database, into the $user_background variable.
Thus, the code on the user page looks something like this:

<body style="background: #282b31 url($user_background) 50% 0 repeat;">
...
</body>

The user inserts his link example.com/image.png and in the page code, it looks like this:

<body style="background: #282b31 url(http://example.com/image.png) 50% 0 repeat;">
...
</body>

It would seem that this is not the case. If the user inserts something here other than an image, then nothing will happen, according to the rules of CSS, why filter something or ... not.
Suppose a school hacker inserts some tag instead of a picture: In this case, as a rule, nothing will happen, but the layout may move, which is already a sign of vulnerability. Further, our khakir will bomb his navel and he will ask for help from his older brother from the Onanimus group. The good brother will change this line so as to turn it into an active XSS vulnerability (it's correct to say "promote" it). At this stage, the line will look something like this:
She will not only happily greet everyone who comes to this page with an alert, but also install an image and will not spoil the layout of the site, and besides, it will not violate CSS rules. So, this is the XSS vulnerability.
By the way, they are of several types. Active and passive.
To broaden my horizons in the field of XSS, I recommend reading the manual, as old as mammoth's droppings, on the Antichat forum: forum.antichat.ru/threads/20140/ (strange, the link is being cut, isn't Achat banned on the Toaster?).
Due to the lack of filtering, the text from the field is stored in the database in its original form. As soon as he hits the page, the fun begins ^_^.
First, the code sets the image to the background, then safely closes this tag. After that comes the "payload", that is, JS code, for example. With the same success, you can shove there, for example, the test tag or a bunch of links to the sale of Viagra with anchors, thereby raising some indicators, for example, the citation index (TIC) for your links. After that, we create a new input tag, make it hidden, and thereby close the tag (by html standards, this element does not need a closing tag). The vulnerability is ready.
Well, if this is not enough for you, then you can "win the admin" with the help of social networks. engineering and... the same XSS. To do this, just change the JS code to something like:
and if the nuboadmin does not have httponly cookies, then you can get the admin data and log in under his account or even get into the site admin panel. Then you can fill in something, but that's a completely different story ...: 3
At least in this particular case, wrap the $user_background PHP variable in

htmlspecialchars($user_background, ENT_QUOTES, 'UTF-8');

thus, the code shown above will no longer work. Next, you need to set httponly for session Cookies (if not already), for this you need to replace your construction with something like this: or like this
well, in general, before writing something, it is better to read at least one book on PHP7.x, JS ec6, HTML5, CSS3. I haven't read them myself, so you can ask it here as a new question. There are guys here who can suggest really suitable and modern literature.
Good luck with learning XSS.