0

So, I've noticed that XSS primarily relies on unescaped angle braces to insert html markup. I have this code here:

<!doctype html>
<html lang = 'en'>
<head>
    <meta charset = 'utf-8' />
    <title>XSS Blocker</title>
    <style>
        textarea { width: 400px; height: 300px; margin-left: auto; margin-right: auto }
        #abc { background: white; }
        div { background: blue; }
    </style>
</head>
<body>
    <div id = 'abc'>    

    </div>
    <br>
    <textarea id = 'noXSS'> </textarea> 
    <button type = 'button' id = 'insert'>Insert into page</button>
    <button type = 'button' id = 'toggle'>Disable XSS</button>
</body>

<script src="https://code.jquery.com/jquery-1.10.2.min.js"></script>
<script>
$(function() {
var noXSS = false;

function cleanInput(input) {
    return input = input.replace('<','&lt').replace('>','&gt');     
}

$('#toggle').mousedown(function() { 
    noXSS = !noXSS; 
    if (noXSS) { 
        $(this).html('Enable XSS'); 
    }       
    else { 
        $(this).html('Disable XSS'); 
    }  
});

$('#insert').mousedown(function() {
    var text = $('#noXSS').val(); 

    if (noXSS) { text = cleanInput(text) }
    $('#abc').append(text);
    $('#noXSS').val('');
});

});
</script>
</html>

Which in essence simply escapes the < and > characters before inserting text into the webpage. In an related question (Escaping < Good Enough to Prevent XSS Attacks), I read that one also has to declare the charset (which people should be doing anyway) to prevent UTF-7 XSS, and should also escape the ampersand, backslash and both the single and double quote characters for safety.

To gain a better understanding of how and why the 'extra' characters (&, ', ") could possibly be harmful (and because it will also be fun to learn), I would like to see code that hijacks my above program using those characters.

I know that this isn't quite a question, more of a quest for knowledge, but I hope it is fine.

Community
  • 1
  • 1
Exabytes
  • 13
  • 3
  • Try posting this on [Programmers StackExchange](http://programmers.stackexchange.com/). This site is more for troubleshooting existing code and yours works. – adamdc78 Jul 23 '14 at 16:52
  • 1
    Escaping `'` and `"` is for preventing injection inside an HTML attribute. `&` is for proper encoding. In general, you should not create your own XSS filter, but use the native methods for setting the text or attribute of an element. Also, your `replace` calls will only replace the first occurrence of the character in the string, so it is not secure at all. – Alexander O'Mara Jul 23 '14 at 17:30

2 Answers2

1

The correct way to handle this is to set the text.

$('#abc').text('What <ever> you & want;');

Then, no escaping is necessary.

Brad
  • 159,648
  • 54
  • 349
  • 530
  • Correct, but only if `'What you & want;'` is actually a variable containing `'What you & want;'` not literal text in the JavaScript. Otherwise [entity encoding is necessary](https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.233_-_JavaScript_Escape_Before_Inserting_Untrusted_Data_into_JavaScript_Data_Values). – SilverlightFox Aug 06 '14 at 16:35
  • @SilverlightFox That isn't true, but I think what you are getting at are all those folks echoing data directly into JavaScript, for which JSON-encoding should be used. You can put whatever string literal you want in your JavaScript code, variable or no variable, as long as you escape it properly... which again is what I think you're getting at, but that has nothing to do with whether or not it's a variable or a literal. – Brad Aug 06 '14 at 17:09
  • Yes, that's what I'm getting at. In your answer it says `What you & want;` not `What you & want except single quote unless encoded;` - that's why it is OK if already safely in a variable, but not if you are putting whatever you want between two quote characters. – SilverlightFox Aug 06 '14 at 17:16
  • @SilverlightFox Ah, I understand where the confusion comes from now. Yes, agreed. – Brad Aug 06 '14 at 17:26
0

To prevent reflected and stored XSS you need to escape/encode part of the response from the server (output fields). Some encoding inside the browser page itself could be useful only against DOM XSS but this is a more rare scenario.

DavidC
  • 218
  • 1
  • 12