The How, What, and Why of Injection Vulnerabilities 

Recently when browsing the forums on DotNetNuke.com I have noticed more and more questions regarding Script Injection vulnerability in the core and third-party modules.  I have often found that at times it is hard for non-developers to truly understand the concept of script injection and what makes a site vulnerable.  So in this article I will take a bit of time to discuss both types of injection that users of DotNetNuke should be aware of, how to test for them, and also how to prevent the vulnerability when creating modules. 

SQL Script Injection

SQL script injection is one of the two common types of injection methods used to attempt to break into web applications.  A person is able to perform SQL script injection if input text is not properly filtered.  One of the most common points for an SQL Injection attack is when working with search methods which are dynamically created.  If proper input filtering is not completed users can bypass the intended process and execute their code.  For example lets say we have a search process that looks through a listing of users and we prompt for the last name, lets look at something that a user might be able to do if they type in the following

Smith';DELETE FROM Users; --

When translated into a dynamically created SQL Statement this might result in the following statement.

Select *
FROM users
WHERE FirstName = 'smith';DELETE FROM Users; --

According to SQL Server this would actually be two separate statements that may be able to execute.  The first is the dynamically created search query, the second is the malicous code that removes all users.  Now this is just one example of how a person might try to inject code.

How to Test For SQL Injection Vulnerability?

You can use many methods to test for a SQL injection vulnerability, however one of the most simple is to simply put a ' in for search terms and see if your application generates errors.  If it errors out, then you will want to be looking in more detail as the key with SQL injection is the ability to terminate an existing statement.

How to Prevent Vulnerability

This is a very easy thing for developers to avoid, simply using parameterized stored procedures instead of dynamic SQL will protect your applications from this type of attack. Because of this it is very uncommon to see this type of vulnerability within your DotNetNuke application.

Other Considerations

One other thing to consider when looking at SQL vulnerability is what type of actions you are looking to complete.  There are certain pieces of functionality that require dynamically created SQL, in these cases a careful eye when testing the application can ensure proper performance.

HTML Script Injection

The other type of vulnerability potential that I will discuss is HTML Script injection, this may be known to you by many different names including cross-site scripting.  The key piece here is an ability for someone to input HTML and/or JavaScript that is executed on a page.  This vulnerability is a bit harder to find a "good" solution to as there are times with working with web based applications, DotNetNuke especially where you will need to allow the injection of JavaScript and other goodies.  I will discuss this balance in the Other Considerations section below.

How To Test?

Testing to see if a module accepts unfiltered Javascript is very easy to do.  You can try to input something like the following into a text field.

<script type="text/Javascript">
    alert('test');
</script>

If after saving the content you are taken to the content and you see a message box that simply says "test", you have a section of your site that is open for someone to put malicous code in place.  A javascript alert isn't anything too major, however, if Javascript is allowed in without any filtering much more severe things could occur.  For those of you that were readers of my blog about 6-9 months ago when I abandoned the DNN Core Forum, a HTML script injection attack was used by a poster to this site to redirect visitors of my forum to google.com.

How to Prevent Vulnerability

This is the hard part when working with items of this nature.  The best method to prevent this is to simply HTML encode all incoming information.  However, this does not allow users to submit any HTML formatted text, and in many cases this is NOT a desirable action.  Many people have thoughts on this issue, some believe just enforcing replacement rules to remove specific offending text, others rely on user practice.  Regardless when working with DotNetNuke there are methods provided by the core team to help filter out content.

Other Considerations

As I have mentioned above this type of vulnerability has many more points to consider before you can implement a solution.  Looking inside DotNetNuke, how would we be affected if we were not able to input JavaScript in the Text/HTML Module?  In the case of this site I wouldn't have my Google advertisements, Google analytics or donate buttons.  The key difference here is that the edit permissions to that module are really restricted to admin users so we can trust our users.  Now as you start progressing to more publicly available input methods such as guestbooks and blog comments you have a new set of functionality that you must make a proper selection on what you allow.

The key point here is that it is easy to prevent, but it can be hard to balance site protection with needed functionaliy.

Conclusion

This was intended to be a very high level overview to try and help those unfamiliar with the different types of vulnerabilities that you need to be aware of when working with web applications.  Please share any questions/comments below.

Share/Save This Article:      

Comments