Prevent Xss Attacks

Preventing XSS attacks in React and NodeJS

Don't sanitize on the client-side before the data is sent to the server - clients are free to run whatever JavaScript validation code they want (including none), and to POST to your server whatever they want.

A good approach is to sanitize as soon as safely possible. Doing this will result in your database will storing sanitized values, which means that security will not depend on also remembering to sanitize on the client whenever rendering something from the database. There wouldn't be any harm in also sanitizing on the client when rendering, though - it wouldn't add any noticeable overhead, and would provide an extra layer in case you had an endpoint that you mistakenly didn't sanitize before saving to the database.

What is the correct way to prevent XSS attacks being included in user provided links?

As its name suggests, the HTML Sanitizer is meant to sanitize html content (especially generated body content, javascript, etc). That is if you put your sanitized string into a html page it will perfectly work.

Just try the following:

<html>
<body>
<a href="https://www.google.com/search?client=firefox-b-d&q=xss+encoding+url">
   Click here.
<a/>
</body>
</html>

Clicking on the sanitized link will indeed guide you to your wanted Google search.

As stated by OWASP

A Positive XSS Prevention Model
(...) treats an HTML page like
a template, with slots where a developer is allowed to put untrusted
data. These slots cover the vast majority of the common places where a
developer might want to put untrusted data. Putting untrusted data in
other places in the HTML is not allowed. This is a "whitelist" model,
that denies everything that is not specifically allowed.
Given the way browsers parse HTML, each of the different types of
slots has slightly different security rules. When you put untrusted
data into these slots, you need to take certain steps to make sure
that the data does not break out of that slot into a context that
allows code execution. In a way, this approach treats an HTML document
like a parameterized database query - the data is kept in specific
places and is isolated from code contexts with escaping.

Your sanitizer is meant to make these slots a "safer" place.

How can I prevent XSS attack in Asp.net Webforms?

You can do at least two things:

Clean HTML fragments and documents from constructs that can lead to XSS attacks using HtmlSanitizer library.
Start using content security policy headers to prevent inline execution of the possible injected scripts.

How to prevent XSS attacks in api mode of Rails?

It's not an attack to receive data like that. It's an attack to display it.

By default Rails escapes within the HTML context, and only within the HTML context, so when you do:

<p><%= params[:name] %></p>

You'll see the escaped version that's rendered harmless. The only way around this is if you go out of your way to declare it safe with html_safe, which you wouldn't do unless you're sure it is safe.

If you have an API-style app with no front-end at all, congratulations, you're immune to XSS attacks. Your clients, however, will need to take precautions to ensure they properly escape any content for the appropriate context in which it's presented.

In other words, Rails won't and shouldn't care unless HTML is being displayed.

Remember, the parameter itself is never altered, it's just escaped before being displayed.

Preventing XSS Attack on Form

You will need a three pronged approach to solve this issue.

Preventing XSS injection:

Note that if a user injected the url value

" /> <script>alert('xss')</script>

this would also leave you vulnerable:

<form name="myform" method="post" action="" /> <script>alert('xss')</script>" >

Therefore you should use the HttpUtility.HtmlAttributeEncode function to solve this one.

However, don't stop there. As noted, you should project against javascript: style URLs. For this I would ensure that the URL begins with http:// or https://. If not, throw a SecurityException which you should be logging and handling server-side, and showing the user a custom error page.

Finally, you want to protect against Open Redirect Vulnerabilities. This is to stop phishing attacks by redirecting users to other domains. Again, use a whitelist approach and ensure that the domain redirected to is one of your own. Be careful on the parsing here, as it is easy to get it wrong - a URL of http://example.org?http://example.com will pass the validation filter for example.com on many badly written validation routines. I recommend using the Uri object in .NET and retrieving the domain through that rather than rolling your own string functions.

You could also check if the URL is a relative URL, and allow it if acceptable. Use something like this function which uses a built in .NET library to ensure that it is relative or not.

Escaping Good Enough to Prevent XSS Attacks

No, for the HTML body you will also need to encode the & character to prevent an attacker from potentially escaping the escape.

Check out the XSS Experimental Minimal Encoding Rules:-

HTML Body (up to HTML 4.01):
HTML Entity encode < &
specify charset in metatag to avoid UTF7 XSS
XHTML Body:
HTML Entity encode < & >
limit input to charset http://www.w3.org/TR/2008/REC-xml-20081126/#charsets

Note that if you want to enter stuff inside of an attribute value, then you need to properly encode all characters with special meaning. The XSS (Cross Site Scripting) Prevention Cheat Sheet mentions to encode the following characters:-

&,<, >, ", ', /

You must also quote the attribute value for the escaping to be effective.