What is a JavaScript injection attack?
A website is vulnerable to JavaScript injection attacks whenever it accepts user input and redisplays that content. Let’s examine a specific application that is vulnerable to JavaScript injection attacks. Let's say you've created a customer feedback website. Customers can visit the website and enter feedback about the product. When a customer submits feedback, the feedback information reappears on the feedback page.
Customer Feedback Website is a simple website. Unfortunately, this site is vulnerable to JavaScript injection attacks.
Suppose the following text is being entered into a customer feedback form:
This text represents the JavaScript script that displays the warning message box. After someone submits this script to a customer feedback form, the message Boo! will appear
to anyone who visits the customer feedback site in the future. You might also think that others won't wreak havoc via JavaScript injection attacks.
Now, your first reaction to a JavaScript injection attack might be to ignore it. You might think that a JavaScript injection attack is just a harmless thing
Unfortunately, hackers are known to inject JavaScript into websites to wreak havoc. Cross-site scripting (XSS) attacks can be performed using JavaScript injection attacks. In a cross-site scripting attack, confidential user information can be stolen and sent to another website.
For example, hackers can use JavaScript injection attacks to steal Cookies values from other users’ browsers. If sensitive information (such as passwords, credit card account numbers, or Social Security numbers) is saved in browser cookies, hackers can use JavaScript injection attacks to steal this information. Or, if a user enters sensitive information into a form field on a page, and the page is compromised by a JavaScript attack, a hacker can use the injected JavaScript to obtain the form data and send it to another website.
Please pay high attention to it. Take JavaScript injection attacks seriously and protect your users' confidential information. In the next two parts, we'll discuss two techniques for protecting ASP.NET MVC applications from JavaScript injection attacks.
Method 2: HTML encoding before writing to database
In addition to using HTML to encode data when displaying it in a view, you can also use HTML to encode data before submitting it to the database.
The second method is exactly the case of the controller in Listing 4.
For example:
public ActionResult Create(string message)
{
// Add feedback
var newFeedback = new Feedback();
newFeedback.Message = Server.HtmlEncode(message);
newFeedback.EntryDate = DateTime.Now;
db.Feedbacks.InsertOnSubmit(newFeedback);
db.SubmitChanges();
// Redirect
return RedirectToAction(“Index”);
}
Please note that the value of Message is in Create( before being submitted to the database. ) operations are HTML-encoded. When the Message is redisplayed in the view, the Message is HTML-encoded, so any JavaScript injected into the Message is not executed.
Generally, people prefer to use the first method discussed in this tutorial and not the second method. The problem with the second approach is that you end up with HTML-encoded data in the database. In other words, the data in the database will contain strange characters. What's the harm? If you need to display database data in a form other than a web page, you will encounter problems. For example, data cannot be easily displayed in a Windows Forms application.