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
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.
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.
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
I will discuss this balance in the Other Considerations section below.
How To Test?
You can try to input something like the following into a text field.
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
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.
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
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.
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.