1
votes

Is it possible to prevent XSS attack simply be preventing any HTML tag (encoded/not encoded) in GET/POST inputs? Also, no (intentional) dynamic data from server side contains any HTML tag.

HTML tags can be prevented simply by a middleware that checks for if any html tag is presented in any GET/POST request.

All my static strings are safe and only dynamic strings are what i have to worry about, and dynamic strings either come from the client (with GET/POST requests) or come from the database, then if i can ensure that non of these characters [", ', <, >, &] are in any dynamic string coming from client or from database, will I be able to avoid XSS?

3
Not fully. Imagine something like this: <script>var something = "<?php echo $_GET['user']; ?>";</script> Or something like this: <img src="<?php echo $_GET['user']; ?>" /> and a payload like #" onload="doevilthings.Alexander O'Mara
What If I also prevent these characters: ", ', <, >, &Ishtiaque Khan
Depending on where the input might be reflected, and how bad the code is, even then it could be possible. Also, I would tend to think there are many places such characters would want to be allowed.Alexander O'Mara
I do not need these characters to be allowed.Ishtiaque Khan
You have to either sanitize by javascript, or if it is disabled, sanitize it in the serverseoyoochan

3 Answers

2
votes

Even if you'd prevent [", ', <, >, &] one could inject bad code. It always depends on what you do with the data sent. Do you want to display it? If so, why not just using htmlspecialchars-equivalent, already existing, tested functions?

By only disallowing the characters stated above, you still could be infected depending on where you insert the data. Imagine the following:

<img src="...." <?=$_GET['data']; ?> />

By inserting onclick=alert(document.cookie) you can also execute code.

As I said, it depends on where you insert the data, but the best practice against XSS (and definitely all other potential attack vectors) is using intense tested, well-known, already existing functions.

In addition, this would also cause potential security issues:

<a href="<?=$_GET['data']; ?>">sometext</a>

...if you'd insert something like javascript:alert(document.cookie) or similar.

1
votes

Assuming you're using PHP:

  • Using MySQL after getting the input:

    $foo = $_POST['bar'];
    $safefoo = $mysqli_instance->real_escape_string($foo)
    

Safefoo will be a sanitized version of the variable

If you're not using mysql, but want to remove special characters

// Strip HTML Tags
$clear = strip_tags($des);
// Clean up things like &amp;
$clear = html_entity_decode($clear);
// Strip out any url-encoded stuff
$clear = urldecode($clear);
// Replace non-AlNum characters with space
$clear = preg_replace('/[^A-Za-z0-9]/', ' ', $clear);
// Replace Multiple spaces with single space
$clear = preg_replace('/ +/', ' ', $clear);
// Trim the string of leading/trailing space
$clear = trim($clear);
1
votes

You can avoid XSS and code injection (and still maintain data transparency) by properly escaping all the input data:

Pseudo-code:

// Pre-processing:
myData=readFromHttp("arg-name");

// ...Processing...
// Use myData only in user sections, not for composing SQL statements:
// SQL statements should be static, and apply dynamic data through placeholders.

// Post-processing: Compose an HTML result:
"<html>"+escapeHtml(myData)"</html>"

The escapeHtml function must perform these replacings in this order:

& --> &amp;
< --> &lt;
> --> &gt;
" --> &quot;

Again, you must use parameters to accept data from user, not code. There are certain regions in HTML when data is accepted:

<a title="data">...</a>
<strong>data</strong>
<p>data</p>

... but there are others where only code (or URLs) is accepted. These must be composed with static code:

<a href="code">...
<img src="code">...
<script src="code">...
<script>code</script>