Learning web security from scratch (2)

Learning web security from scratch (2)

The previous article explains some basic xss knowledge. This article continues to study. I mentioned some theoretical things in the previous article, and I soon forgot about it. After a brief review, we will talk about the xss classification: stored XSS, reflected XSS, and dom xss. I talked about a few simple payloads, which are just theoretical things. I will not continue to look at the theory in this article. I will first try to use payload ~ Fun ~~

Practice

I soon forgot my theoretical things, so I decided to find something to play ~ Start with the imweb blog.

After carefully reading the blog, the easiest thing about xss is the comment box in the article. This comment box Supports rich texts. When rich texts come in, risks also come along.

There are two types of filter rules in the comment box. The 1st type is called a whitelist. That is, only valid HTML tags in the whitelist are allowed, such as IMG. All other items are excluded. The 2nd category is called the blacklist, that is, the manufacturer builds a Harmful HTML Tag and attribute list, analyzes the HTML code submitted by the user, and removes harmful parts.

I tested the comment box of our blog. It should be a blacklist filter.

Preliminary Exploration

I am not familiar with the comment box yet. I can see that the code is compressed. I am too lazy to look at the compressed code =. I just tried it with Rich Text ~~

First, I submitted a very simple payload

View DOM:

There are good news and bad news. We find that onerror and its attribute values are filtered out, but there is also good news. We find that directly submitting html code will not be filtered, this makes it possible for our later xss. OK, continue to try some common ones:

<script>alert(1)</script>

 

The entire href and its subsequent attribute values are filtered out, which is expected. We can simply guess the reason, maybe:

Href is filtered out. (This idea is basically impossible later. How can I send a normal link to href? Of course, markdown can) the code judges the values in href, finds such a thing in it, and filters out all the things behind this href. This is undoubtedly the most likely.

Well, if you want to filter, I will find some unnecessary syntaxes. Try again. This time you don't need:

xss

As a result, we were pleasantly surprised to find that the button did not display any filter:

However, there was no response to the click. I checked the dom:

A little lost. I found that the onclick and subsequent attribute values were filtered out. At this time, I suddenly thought of what I tested before.

The onerror of this payload is also filtered, almost the same situation. So we got another clue. We can speculate that the filtering code has such a logic to determine whether there is any starting attribute of on in the submitted comments. If so, we will filter it out.

Sort out the clues from the previous tests:

Rich Text Labels allow direct submission. scripts to be filtered out. Attributes starting with on are filtered out, such as onerror, onclick, and onmouseover. This filter rule directly wastes a lot of payload. Filtered, which also makes a lot of payload lost. Character entity Problems

Continue to try payload, or think about what the above clues can bring to us? It is still fatal to find clue 3 to filter on. It seems that there is no way to bypass this filter. But clue 4 seems to have a chance!

Here is a simple little knowledge, which is an important step for us to succeed in xss:

In the value of the html Tag attribute, the character entity is converted to a relative character. This means the following two are equivalent:XssXss

 

Is it possible that the code is just a simple judgment and does not process character entities?

I re-constructed a payload and submitted it:

xss

Check the dom after submission, but it is not filtered out! And the parsing is correct!

But the new problem is that there is only one javascipcommand for the code to use, but this part of the code will not trigger the execution, because all the attributes starting with on are filtered out. At this time, the first thing that comes to mind is that JS can be triggered without the onclick attribute similar to the on attribute?

At this time, I thought of the structure summarized by @ sogili, which perfectly avoided on! Use formaction for form hijacking!

X

The result comment is as follows:

I have tried it before and the button will not be filtered out. Unfortunately, the form is in the blacklist and the DOM is viewed as follows:

Okay. In this step, there is an idea of how to bypass the code that form is filtered into strings. After a bit of entanglement, I did not think of a good way to work. But will there be a ready-made form available on the page! Simply use formaction to hijack the existing form on the page!

Excited, I quickly searched for the keyword form and found a form!

Sorry .. This form does not have the id attribute. It turns out that whether there is an id can affect the success of hack. It is lucky to say that the form does not have an id here, because the form attribute of the button needs to carry an id, no id can be used for hijacking.

Well, I didn't think of a good way to keep thinking about this idea ..

Review our ideas. Our current progress is:

Rich Text Labels allow direct submission. scripts to be filtered out. Attributes starting with on are filtered out, such as onerror, onclick, and onmouseover. This filter rule directly wastes a lot of payload. Filtered, which also makes a lot of payload lost. However, the character in the replacement of character entities in the button can be bypassed! Buttons are not blacklisted, such as iframe and form, and are filtered into strings. Animate Bypass

The greatest progress we have made is clue 4. At this time, we may have thought that javascript is not easy to handle. Simply adding the tag is not enough! That's what I thought at the time. Can I use a single character or entity to perform xss smoothly? The situation was not as smooth as expected. I directly used the following payload:

test xss

No surprises. Href is filtered out. The following two inferences are obtained:

In tag a, it seems that there is no problem with the character entity. In visual testing, there is a problem with the character entity only when the label is like a button (because on is processed. Maybe the entire href is filtered out.

Case 2 is very easy to verify. You can simply submit a normal a link ~ The test found that 1 is correct, and 2 is wrong. However, it was inferred that 2 gave a new nice idea. It is not acceptable to directly submit the tag, but the tag can be nested in svg! Therefore, try the following structure:

 
                     
              
  
   test
          
 

Try to use the tag in svg. Unfortunately, the content in xlink: href is also filtered out ..

The character entity issues that are hard to find do not exist in attributes similar to href. What should I do?

Is there a way to make xlink: href insensitive when submitting a string, and set it back later. The answer is yes!

Still, as summarized by @ sogili, an animation can be used to change an attribute value in svg. The same applies here. Let's first look at payload:

 
                     
              
  
   hack
                       
 

 

There is no character entity in href, xlink: href. Leave xlink: href blank to prevent filtering. However, most of the attributes of other tags have character entities, and animate is no exception! In animate, the attribute value of xlink: href is changed through to = "javascript: alert (1)" and the comment box is filtered out !! XSS successful! See the figure below:

Summary

I did understand a lot of things when I tried it. during development, many things may not be noticed by myself, mostly because of insufficient security awareness. This simple hack has made me try a lot of interesting things ~~