Develop Reference

Safely encoding <script> content in ASP.NET Core (ETAGO Problem)

The project I am working on requires user generated server data to be encoded to JSON and sent down with the HTML document in script tags. At the moment I am doing this with the TagBuilder class using the InnerHtml.AppendHtml(...) method to write the script content.
I have since discovered I have to escape / encode the script content as if the user content has for whatever reason the text "</script>"somewhere, the HTML parser ends the script tag (other HTML probably has various side effects as well).
I read this blog post which describes how to handle the situation in an Node.js environment by using the jsesc library. Does anything similar exist for .NET (ideally Core or Standard)?
I wanted to ask before I roll my own as I'm always weary of doing that for security related code.
Edit
Due to time constraints, for the time being I have injected the JSON into a HTML element as an attribute value, and the ASP.Net Core engine automatically encodes those correctly.
Unfortunately it does increase the size of the HTML document a little more than I would like, as double quotes are encoded as ", but it is what it is.
I'm leaving this question open though in case an answer to my original question comes along.

use flatedecode filter when embed javascript in PDF, using php FPDF

I want to create a dynamic PDF file with javascript embedded, using php code form this link:
http://www.fpdf.org/en/script/script36.php
but the javascript is plain text in the PDF file, is there any way to add 'flatedcode' filter to the javascript code, and use it as PDF stream object, so that there's no plain text javascript code presented in the final PDF file?

Yes, though not exactly with the code you point to. The code creates a dictionary with a "JS" element as a text string.
If you read the PDF reference you'll see that this "JS" element can be either a text string or text stream. As it can be a text stream it could get a FlateDecode filter. Should you would have to modify the code to create not a string but a stream and to encode the stream with Flate.
I do hope you realize that the use of automatically executed Javascript on document open may simply not work and could be very obnoxious (to say the least).

Preventing / understanding xss with javascript encoding

I'm currently reading up on .net MVC and have just reached the security chapter of the book. I've known about xss, and I never trust any user input without sanitizing it first (usually with html encoding or even something like php's strip_tags). Up until this point I was not familiar with Javascript encoding strings for protection. One of the examples in the book had a user pass in a string like:
\x3cscript\x3e%20alert(\x27test\x27)\x3c/script\x3e
So naturally when I learn something new I want to test it. I created this:
public ActionResult Index()
{
ViewBag.test = "\x3cscript\x3e%20alert(\x27test\x27)\x3c/script\x3e";
return View("index");
}
and this view code that prints out the test string on the page:
#ViewBag.test
However, I cannot get this alert box to show at all. When I view source on the page I get
<script>%20alert('test')</script>
I've tried playing with it a few different ways
Passing the #ViewBag from a query string
putting the viewbag print inside of existing script code (this is how the book had it)
Replacing the %20 with actual spaces
Using jquery to replace html with ViewBag.test:
$('#inject_here').html('#ViewBag.test');
Nothing I try will execute this code (which I guess is a good thing?). Now I know there wouldn't be a portion of this book dedicated to something that didn't work in the first place, so the problem must be on my end. I just don't know what it is. Any one have any ideas?

asp.net MVC tries to take care of this issue for you. It automatically encodes output. You must go out of your way to print out a string without html encoding it.
#Html.Raw(ViewBag.test)
There are places where you will end up doing this in an application. Ideally you would have templates that models are rendered into. But, in some cases you'll have sections of HTML that are dynamic and need to be printed as is. In those cases you'll use the Html.Raw and just need to be aware that you must validate the sanity of the content.

using decodeURIComponent within asp.net

I encoded an html text property using javascript and pass it into my database as such.
I mean
the javascript for string like "Wales&PALS"
encodeURIComponent(e.value);
converted to "Wales%20PALS"
I want to convert it back to "Wales&PALS" from asp.net. Any idea on how to embed
decodeURIComponent(datatablevalues)
in my asp.net function to return the desired text?

As a prevention for SQL injection we use parametrized queries or stored procedures. Encoding isn't really suitable for that. Html encoding is nice if you expect your users to add stuff to your website and you want to prevent them injecting malicious javascript for instance. By encoding the string the browser would just print out the contents. What you're doing is that you encode the string, add it to the database, but then you try to decode it back to the original state and display it for the clients. That way you're vulnerable to many kinds of javascript injections..
If that's what you intended, no problem, just be aware of the consequences. Know "why" and "how" every time you make a decision like this. It's kinda dangerous.
For instance, if you wanted to enable your users to add html tags as a means of enhancing the inserted content, a more secure alternative for this would be to create your own set of tags (or use an existing one like BBCode), so the input never contains any html markup and when you insert it into the database, simply parse it first to switch to real html tags. Asp.net engine will never allow malicious input during a request (unless you voluntarily force it do so) and because you already control parsing the input, you can be sure it's secure when you output it, so there's no need for some additional processing.
Just an idea for you :)
If you really insist on doing it your way (encode -> db -> decode -> output), we have some options how to do that. I'll show you one example:
For instance you could create a new get-only property, that would return your decoded data. (you will still maintain the original encoded data if you need to). Something like this:
public string DecodedData
{
get
{
return HttpUtility.UrlDecode(originalData);
}
}
http://msdn.microsoft.com/en-us/library/system.web.httputility.aspx
If you're trying to encode a html input, maybe you'd be better off with a different encoding mechanism. Not sure if javascripts encodeURIComponent can correctly parse out html.

Try UrlDecode in HttpServerUtility. API page for it

XML and Javascript: the right tool for the job?

For years I've been reading about XML and I have just not quite grokked it. Most documents I see about it simply explain the syntax (extraordinarily easy to understand) and say that it's portable: I've worked with Unix my whole life so the idea of putting things in plain text to be portable is hardly revolutionary. My specific question is that I have a document (my CV) that I would like to present to web visitors in several formats: as a webpage, as a pdf, or even as plain text. Is XML and Javascript the right approach to take?
What I need is for the document to be easily editable, conversion easy and just easy general upkeep. For example, when I publish a paper, I'd like to take less than five minutes to add the info and then have everything go automatically from there.
Give me your opinions: I also use LaTeX compulsively, so my current approach has been just to have my CV in LaTeX and to convert it to a web-page using LaTeXML. However, I sorta have the feeling that with everybody jumping up and down about XML and Javascript, that there might be something good to learn about it.
I would also like to simplify maintaining my homepage by not duplicating the same footer for every single page that I set up.
Thanks,
Joel
Edit: I'll also take any book recommendations!

I think this is a slight misunderstanding of the combination of JavaScript and XML.
XML, in and of itself is an excellent means of representing data. It's largely human-readable, and easily parsed with libraries in nearly every programming language. That is the main benefit of XML.
Using XML with JavaScript is certainly a solution, but I think it's a matter of the question you're asking. JavaScript can parse XML, and allow you to obtain and manipulate data from your XML document. If you want to grab data from a server without reloading your HTML page (synchronously or asynchronously), then using JavaScript and XML is a valid way to do that.
If you want to, however, display your XML as a webpage, you would likely be better off using XML and XSLT [wikipedia], or perhaps PHP and XPath, to transform the document into browser-readable HTML. On the other hand, you could use nearly any language to convert the XML to a plain-text file, rich text file, or store it in a normalized database.
To sum up, XML is a great way to store data, because it can be used in so many different ways, and by so many different languages. It's an answer to many different questions; you just have to figure out which questions you're asking.

To elaborate on my comment
The transformation to whatever output you desire is depending on how you store your CV on your server and whether you have the possibility to process it on the server. If you store it in XML, you can transform it to desired (binary) output using server based tools - that would for php be pdf and word (on windows server platform) for example. XML would be interesting from a mark-up point of view since it would make it clear where the table of contents, headers, lists of experience and so one would be found.
JavaScript cannot transform something into PDF or word, that has to be done on the server. What javascript can do is to get a text from the server in XML or JSON using AJAX and manipulate this into what the user sees on the screen. For XML that can be done with XSL(T) too. If you want for self-education purposes to use JavaScript, JSON is very nice since it is in my opinion more readable than XML and it creates a populated javascript object with the least work.
Footer in javascript: in the page have
<script type="text/javascript" src="footer.js"></script> and in footer.js, you can for example do
var footerText = 'Here goes whatever you want';
document.write(footerText);
Comparison between XML and JSON

I've got a webpage with browser-side XSLT transformation up and running for years. It's a playground, only some words in german. See how easy it is to build this on heese.net/test. You can switch between "Beispiel" (=Demo) and XSL. The sourcecode of the page in the iframe is the XML. You can do this serverside with 3 lines of PHP-code.
On Javascript: you can use it with XSLT and I show this on my site, but it can't interact. First the XSLT builds an HTML page out of your XML data and after this job is completely done the Javascript in the resultig HTML document begins to work.
Parsing XML with Javascript is a different task.