I'm learning about XSS and I found I can inject code in this tag a few days ago.
Tag:
<div id="pagenotfound" title='Cannot find /it/search/testtesttesttetst\'onload=alert(1)'>
My payload:
/testtesttesttetst'onload=alert(1)
URL:
/it/search//testtesttesttetst'onload=alert(1)
I have locked < > " & % and many more characters (When I put ' automatically becomes this \' )(The last ' already comes with the page). So, is possible to inject any type of XSS payload in this website?
Yes, XSS is possible.
Escaping is not a proper defense against XSS in a HTML attribute value context because the HMTL parser doesn't care about escaping (it only cares about encoding).
When you have <div title='test\' foo=bar '>, browsers will interpret foo as an attribute and bar as a value.
So why isn't your payload firing? Because onload is not a valid attribute for div. What will work is a payload such as test\'onmouseover=alert(1) :
<div title='test\'onmouseover=alert(1) '>test</div>
In some browsers, you can also gain XSS without user interaction in a div, see eg here.
escape() encodes a string by replacing special chars with escape sequences for usage in URLs. Backslash-escaping just - per definition - doesn't exist in HTML, but other escape methods do.
To prevent XSS attacks you should use a multi-faceted approach.
Does escaping quotes in a HTML attribute context prevent XSS?
Let's use the term "contextual output encoding" instead of escaping as part of this conversation.
"HTML Escaping" means you are taking "data" which may be interpreted by the browser as "control / instructions" and ensuring that it will only be treated as data.
However, not all data will end up in an "HTML context". It is possible that you may be dynamically adding content to JavaScript, CSS, JSON, etc. What constitutes a control character or special character in each context is different. The overarching idea is to make it clear to the client / browser/ downstream system what is "data" and what is "code".
Moreover, escaping/encoding should be applied as close to consumption by the client as possible. While you are processing the data you may need the "raw" data and you may need to send the same input data to multiple output contexts.
In your example the onmouseover={X} attribute is expecting JavaScript, not HTML. Since you are already inside the attribute the angle brackets aren't the major concern because tags aren't an instruction in JavaScript. You are using a blacklist approach here, which may not take into account all Unicode characters and other weird things. A validation/whitelist approach may be more useful here (Limit to what "should" be here).
As a side note, beyond XSS injection, an attacker may be able to just insert HTML or additional attributes which may have unintended/malicious impacts in your app. E.g., beyond XSS, if an attacker could add a regular <a /> link on your page that could be used to redirect the user to a malicious page. in this case, if an attacker can "break out" of the attribute (go beyond the final quote/double quotes) it is another opportunity to add in attacker controlled "instructions".
In addition to output encoding, you should also perform input validation. Input validation is a go/no go decision on whether you should take in data in the first place. It is based on a combination of business and security rules. For example, if you have some field in your app "projectid" and it is defined as a non-zero integer, you should never allow this value to be a string or decimal value. This is breaking the expected convention and you should stop processing and throw and error/exception. After validation, you may also want to apply sanitization, which is where you clean up data and remove/replace values that you do not want present before the processing. For example, if you are processing data for HTTP headers, you will want to replace line-break and special characters like backspace which could be improperly processed.
Lastly, you will also want to implement Content Security Policy. CSP helps to restrict what code is allowed to run based on things like location, integrity hash, etc. CSP is very useful, but not that often you can't use is as a "silver-bullet" because you may need to use scripts that change without notice / outside your control like third party traffic analytics scripts. To learn more about CSP, start with this documentation on MDN.
You should be using a combination of these techniques to mitigate XSS.
For a good starting point, you can also check out the OWASP XSS Cheat Sheet.
To get more depth on contextual encoding, check out this video by Jim Manico starting ~7:00
