Archive for HTML-injection tag
Thoughts on awareness of security vulnerabilities & full disclosure
HTML, SQL and XSS injection vulnerabilities aren’t new but they are still largely ignored by developers.
My first encounter with these issues was in 1999 whilst writing an extranet e-commerce web site. Back then the ASP fix consisted of Server.HtmlEncode for all output and a Replace(“‘”, “””) for strings heading to SQL (other types headed there via CInt/CLong/CDate and I wasn’t aware of parametrised queries).
Convincing co-workers on the severity of the issue and what to do about it for several years can be a draining process when you work with such a variety of different developer personalities and projects and you would rather be spending the time on more exciting things
Over the last few months I’ve been trying hard to push the message further afield via presentations at the local user group, articles here on my blog, discussions in Redmond as well as forums and private mailing lists.
More than once I’ve had the feeling I should give it a rest in case people think I have nothing else to talk about and at a few times I’ve considered publishing a few scripts I had in my head to really show the sort of things available. Of course doing such a thing would both highlight the problem but also provide a dangerous tool to people who might use it to actually exploit sites which is a problem with full disclosure. In the end my article How dangerous is HTML injection was a much neutered version without a killer payload.
Thankfully some great people are now on the case including Rob Conery and Phil Haack who I believe in to push this from inside and Steve Sanderson who came up with an elegant prototype on how to handle this at the source.
That will be all the HTML injection posts for a while I hope for there are many other things I want to work on and write about.
[)amien
5 signs your ASP.NET application may be vulnerable to HTML injection
If you don’t encode data when using any of the following methods to output to HTML your application could be compromised by unexpected HTML turning up in the page and modifying everything from formatting though to capturing and interfering with form data via remote scripts (XSS). Such vulnerabilities are incredibly dangerous.
Using MonoRail or Microsoft’s MVC does not make you automatically immune – use {! } in MonoRail’s Brail engine and the HtmlHelpers in Microsoft’s MVC to ensure correct encoding.
Just imagine post.Author contains “><script src=”http://abadsite.com”></script> after an unscrupulous user entered that into a field your application uses and it got into the database. The following typical ASP.NET techniques would leave you open.
1. You use <%= %> or <%# %> tags to output data
Example showing outputting literals with <%= %> :
// Vulnerable
<p>Posted by <%= post.Author %></p>
// Secure
<p>Posted by <%= HttpUtility.HtmlEncode(post.Author) %></p>2. You use Response.Write
Example showing writing out attributes with Response.Write and String.Format, again post.Author could contain <script>:
// Vulnerable
Response.Write(String.Format("<input type=\"text\" value=\"{0}\" />", post.Author);
// Secure
Response.Write(String.Format("<input type=\"text\" value=\"{0}\" />", HttpUtility.HtmlAttributeEncode(post.Author));3. You set HRef or Src on HtmlAnchor, HtmlImage or HtmlnputImage controls
In general the HtmlControls namespace are very well behaved with encoding but there is a bug in the code that attempts to adjust the relative url’s for href and src attributes which causes those properties to bypass encoding (I’ve reported this to Microsoft).
Example showing anchor HRef attribute abuse:
// Vulnerable
outputDiv.Controls.Add(new HtmlAnchor() { Text = "Test", HRef = post.Author } );
// Secure
outputDiv.Controls.Add(new HtmlAnchor() { Text = "Test", HRef = HttpUtility.HtmlAttributeEncode(post.Author) } );4. You set the Text property of WebControls/WebForms
You would imagine the high-level WebForms controls would take care of encoding and you’d be wrong.
Example showing the Label control being so easily taken advantage of:
// Vulnerable
outputDiv.Controls.Add(new Label() { Text = post.Author } );
// Secure
outputDiv.Controls.Add(new Label() { Text = HttpUtility.HtmlAttributeEncode(post.Author) } );5. You use the LiteralControl
LiteralControl is a useful control for adding text to the output stream that doesn’t require it’s own tag. It also helpfully, and uncharacteristically, provides a useful constructor. Unfortunately it fails encode the output.
Example showing poor LiteralControl wide open:
// Vulnerable
outputDiv.Controls.Add(new LiteralControl(post.Author));
// Secure
outputDiv.Controls.Add(new LiteralControl(HttpUtility.HtmlEncode(post.Author)));- Encode data in the database – your contaminated data will be difficult to use elsewhere and will end up double-encoded
- Look for script on submit – you won’t catch every combination and it might prevent valid data
- Trap entry with client-side code – it is trivially bypassed
Just encode the output :)
[)amien
(The samples use .NET 3.5 object initializer syntax for brevity as many affected controls do not have useful constructors)
How dangerous is HTML injection?
A few years ago I believed that HTML and SQL injection vulnerabilities were headed for extinction. Thanks to object-relational mapping tools SQL injection continues to die but HTML and script injection vulnerabilities are as popular as ever.
Part of the problem stems from the “back-to-basics” approach to rendering web pages, throwing out classes and controls for string-based libraries (primitive obsession) and helpers which do not encode HTML or even offer a concise simple syntax to do so.
MonoRail was one such project but they took feedback on board and addressed the issue although I was surprised it had got as far as release candidate 2 with such a serious oversight.
Other projects have been less reactive when advised of the problem and I can’t help but wonder if I am not getting the severity of the issue across. This isn’t just an annoyance but a real security problem.
- HttpUtility.HtmlEncode (.NET)
- Server.HtmlEncode (ASP)
- htmlentities/htmlspecialchars (PHP)
- html_escape (Rails)
- {! } (MonoRail Brail)
and your web apps output data then they are likely open to HTML & script injection vulnerabilities.
Vulnerable code often looks like this:
myLabel.Text = Request.Form["Something"];
Response.Write(Request.Cookies["AddedProduct"]);
<%= myDataReader[0] %>
<? php echo get_the_title() ?>For more ASP.NET examples check out 5 signs your ASP.NET application may be vulnerable to HTML injection.
Let’s start by considering the actors involved:
Visitor to visitor
If your site stores input from an external user (visitor) and displays it to another then you could be exposed to this scenario. Many sites do this although it is not always immediately recognised – an internet banking site does not seem an obvious candidate until you consider that you may put a textual reference on payments made to another person. If you know they use a vulnerable internet banking solution…
A worst-case scenario here would be that one visitor could steal another’s login credentials and exploit whatever rights that might give him – anything from posting messages to stealing funds.
Visitor to staff
Not all sites exchange data between users but if your site collects information from visitors chances are it presents this information to staff. Internal systems used to examine it are often considered less vulnerable which is a mistake. Remember *all* data provided from a user should be considered to be a potential avenue for a dangerous payload, e.g. even the language-accepts or user-agent strings.
When exploited internal systems can reveal information in bulk about the users, the system and the administration accounts used to manage it. Gaining access to these details brings all the privileges those accounts have to offer which can be catastrophic.
Staff to visitor
It is easy to forget that many frauds are perpetuated by people on the inside. A staff member given the ability to present text to the user via a website has the ability to modify any page that the content is presented on which if it includes a login page (perhaps for system status messages) then capturing login details to a server of their own choice is easy.
Security operators with access to reset (but not view) passwords would find this attack particularly enticing given that they do not need to reset the users account and therefore raise any awareness. An insider can perpetuated the fraud and may be in a position to further conceal it within the organisation.
Next steps?
I can envisage a sequence of steps that start with discovery of injectable systems through detection of script-enabled into form capture-and-forward and async logging of passwords through XmlHttp.
Detailing those steps would certainly raise awareness and help developers appreciate the severity of the issue but how do I make sure that information isn’t abused?
Disclosure is a double-edged sword but then you can’t have security through obscurity… I wonder how many crackers/black hackers already utilise these techniques for nefarious means.
.NET developers might like to check out the slides from the Web Application Security talk I gave at the Guernsey Software Developer Forum which demonstrates exploitable, exploits and safe alternatives for preventing HTML and SQL injection.
[)amien
Security vulnerabilities are not acceptable in sample code
Earlier this week the ASP.NET article of the day linked to 4-Tier Architecture in ASP.NET with C# which I noticed suffered from both HTML and SQL injection. I promptly informed the author and the ASP.NET site (who pulled the link) but the author was rather unconcerned and wrote (after editing my comment):
Thanks for your feedback Damieng. Sql statement has been used here to make the tutorial simple, it is informed in the DAL description.
The problem is people borrowing this code may not notice the vulnerability or understand how to fix it. This isn’t the first time I’ve seen easily exploited sample code, responded and been buffed off with the it’s just sample code excuse.
Writing secure code isn’t difficult, time consuming or confusing to read.
Microsoft’s forthcoming LINQ toS QL and Entity Framework provide object-relational mapping that takes care of the SQL, as do other well-known ORM tools such as SubSonic and NHibernate.
If you must write your own data-access-layer (DAL) code use parameterised queries and not string concatenation.
When outputting values be 100% sure whether your technique will encode the values for you or not and be aware of what encoding tools are available to you.
ASP & ASP.NET’s Response.Write and <%= %> methods do NOT encode for you and you should be using HttpUtility.HtmlEncode to output data to a HTML stream.
Samples of vulnerable and secure code are in my presentation on Web Security I gave at the Guernsey Software Developer Forum a few months ago.
[)amien
Investigating MonoRail
Fighting WinForms
I hate fighting with a technology to get it to do what I want because it means I either have the wrong expectation or wrong technology.
With web development I expect strict web standard support and clean code that is easy to maintain.
I am, therefore, tired of fighting with WebForms and seeing as I’m not prepared to change my expectation then the technology must change.
Looking at MonoRail
Ruby on Rails is very fast, elegant and powerful but comes with a bunch of unknowns. The IDE’s I’ve tried have been so-so, there is no support for IntelliSense so I’m forced to remember exact property and method names. There are concerns about performance and scalability and I find the Ruby language itself cryptic.
My current .NET environment has all these things, so what I’m really looking for is an alternative to the WebForms element itself. It also has a powerful framework, tons of samples, and C# is not only enjoyable but very in-demand :)
MonoRail seems to be just what I am looking for but there are a number of things keeping me away. I decided to spend an hour watching a screen cast on WinForms and MonoRail from Ayende @ Rahien’s blog. It calmed some concerns but raised a few others…
NHibernate mapping files
NHibernate provides the core ORM system within MonoRail and normally requires XML mapping files to do so.
I really don’t want or need another abstraction layer here – my tables are freshly modeled and represent my domain classes very well. Rails, Subsonic and LINQ to SQL are all happy to just do it/
Thankfully a project called ActiveWriter gives you a very LINQ to SQL-like experience in dragging tables off, changing names and properties if you want and doing the magic for you.
ActiveRecord template
I still don’t like this mix of static and instance methods providing some sort of split between what should really be two classes but I can live with it.
There is also a Repository<T> option mentioned which perhaps solves this, I shall have to investigate it further.
View engines
There are a number of view engines available for MonoRail but the primary ones are NVelocity and Brail.
As I already have C# and JavaScript in my project and I have no desire to add another language unless there is a good reason to do so. If they want to stop people writing too much view code then what is wrong with a subset of C#?
The template engines also mean giving up strong typing (everything is passed to the view in a type-less property bag accessed with a string key!) and a complete lack of IntelliSense (the demo stalls as fields are mistyped on occasion proving just how useful this is).
HTML injection
Yes, in this day and age HTML injection should be a long-dead concern and yet even the built in SmartGridComponent will happily squirt out data without encoding it and thus allowing data from anywhere to contain HTML ready to be injected into an unsuspecting page.
Ayende has investigated the issue now and is working on getting a fix into the tree.
[)amien