Great Ideas. Always Flowing.

We are not happy until you are happy. Client satisfaction guaranteed. Whatever your needs and requirements, we have the skills and resources for the job!

Recently Viewed...

To help you navigate to pages you most recently visited, select from the links below.    
Installing / Setup of SharePoint 2010 Part 2
Installing Microsoft SharePoint Foundation (MSF)...

Popular Tags...

Tags

SnowCovered Top Sellers

Frustrated over the lack of customization for your user's registration fields? Dynamically setup your DNN Portal with custom registration fields, layout, questions, and other core integration options......

Ultra Video Gallery is a brother product of Ultra Media Gallery, UVG allows you to upload videos in various format and automatically encode them to flv or H264 format, you also can add videos from internet or record live videos from your webcam.

Build high performance, completely customizable data-entry forms and views driven by your DNN and external databases. New built-in tools make it a snap to quickly create data entry forms, data views, and even database tables. Plus, add your own HTML, CSS, Javascript, SQL commands, stored procedures,

The most advanced DotNetNuke shopping cart on the planet. Easy to use e-Commerce, Secure Shopping Cart Software and SEO friendly. B2C / B2B Ecommerce Sites.

One stop solution for events calendar and events registration! FREE DOWNLOAD is available now!

Secure Programming Tips - The Dangers of 3rd Party Software

Week 7: Dangers of 3rd Party Controls

 

At some point in every developers career, he or she will be forced to make a decision (or management will be forced to make the decision) to utilize the power, functionality and convenience of a 3rd party control or package. Often times this decision is based on the need for the application to contain particular functionality, mixed in with the realization that implementing that functionality from scratch would be expensive and time consuming. 3rd party controls and software can often be a godsend. A developer faced with the requirement of having a discussion forum, is often quite thankful that there are literally hundreds of pre-built 3rd party forum software available for purchase all over the internet. These pre-built forums could be just barebone software or they could contain a plethora of functionality. There are various situations where a 3rd party control or software package may be needed. A suite of custom controls containing specialized form objects designed to make even the toughest programming task 100% easier. A custom menu for navigation purposes whose functionality can be implemented just by adding an additional script tag to the page, and adding a couple of menu items to a configuration file. These are often the very types of 3rd party controls that developers use on a daily basis.

 

Although, the power, functionality and convenience is a major draw when considering the implementation of a 3rd party control, we often overlook the security aspect of a controls implementation. How do we know the software we are implementing is secure? How do we know the control or software we are going to place on a page or use throughout the application isn't going to end up compromising the security of our application? The answer? We can't. At least not without ensuring we have properly and thoroughly tested the control or software prior to its implementation and usage. Sometimes we can get so blinded by the "shiny thing", as a friend of mine Rick used to say, that we end up overlooking other areas of the control that might raise questions, such as it's overall security. In the rest of this article I will provide two "shining" examples of 3rd party controls/software, that when implemented, ended up compromising the security of what otherwise might have been a secure application.

Note: Both software companies below were contacted directly regarding the security issues found in their software. To date neither issue has been fixed. For legal reasons I am prevented from publicly disclosing the names of the two companies I reference below. Just a reminder...Use all 3rd party software at your own risk.

 

Example 1: Company A

 

Company A is a fairly well-known software company that provides, among other things, pre-built JavaScript navigation menus for use in ASP.NET applications. These menus are easy to implement, since they only require adding an additional script tag reference to a page and changing some settings in a configuration file. For anyone familiar with the input validation built into .NET, we can set the validateRequest tag like this <pages validateRequest="true" />. This setting can be placed either at the page level for a specific page, or at the application level in the web.config file. This setting, when set to "true", ensures all requests are passed to the built-in validation routines that will validate the request to ensure it doesn't contain malicious characters. This validation routine is very effective at preventing 99% of all known XSS (Cross-Site Scripting) attacks. Now, the primary issue with this control is it's implementation and usage requires the built in .NET validation to be turned off, i.e. it requires the validateRequest property to be set to "false". Which is an extremely bad thing, as this leaves either the page or the entire application vulnerable to input validation attacks. If this setting were not turned off then the page would throw an error when passing the malicious characters in the examples below.

 

 

When Company A's JavaScript menu is placed on a page, it creates a large amount of JavaScript within the page itself, which obviously can be seen client-side. What this menu does is it takes the page name and any querystring arguments that were passed, such as "http://www.mydomain.com/Details.aspx?ID=1101", and appends them into the javascript on the page, similar to that seen in Figure 1 below.

Figure 1

DMI[7]=((new DMMenu()).ini("Details.aspx?ID=1101",[followed by other parameters used to build the menu]));DMI[7].nz();

A simple test we can do to determine if it accepts user-supplied input is to modify the URL by appending our own querystring value to the end, like this "http://www.mydomain.com/Details.aspx?ID=1101&t=blah" we then submit this request back to the server and view the source to determine if it was added, which it was as seen in Figure 2.

Figure 2

DMI[7]=((new DMMenu().ini("Details.aspx?ID=1101&t=blah"",[followed by other parameters used to build the menu]));DMI[7].nz();

Notice we appended a double quote (") to the end of the querystring? If the built-in .NET input validation, the validateRequest property, were set to "true", this would get HTML encoded in the response, thus rendering it in the browser source as &quot;. Based on this we can make the assumption that the built-in validation is turned off, i.e. the validateRequest property is set to "false". But, in order to verify this, we have to perform additional tests. The next test it to attempt to pass it known malicious characters, characters that the built in .NET validation would prevent and end up returning an error to the user. Our next test would be to modify the URL to this "http://www.mydomain.com/Details.aspx?ID=1101&t=blah"<. We can see the response in the source in Figure 3.

Figure 3

DMI[7]=((new DMMenu().ini("Details.aspx?ID=1101&t=blah"<",[followed by other parameters used to build the menu]));DMI[7].nz();

As we can see, the malicious character was not only allowed, thus confirming the built in .NET validation is turned off, but it also appends the malicious character to the JavaScript in the page.

Obviously, as a hacker, we can now make the assumption that the built in .NET validation has been turned off, thus leaving the application vulnerable to our attacks. So our next attack request will test whether or not we can cause the page to throw a JavaScript alert box. Why this? Because this is the simplest way to reveal whether or not the application might be vulnerable to an XSS attack. Since we can look at the code and determine the appended values are still within the JavaScript code itself, we must modify the URL to escape out of the JavaScript and write our malicious content into the page directly to verify if it's vulnerable. We can modify the URL like this "http://www.mydomain.com/Details.aspx?ID=1101&t="));//--></script><script&gtalert('XSS_IS_IN_MENU');</script>". We can see in Figure 4 below, that we have successfully closed the JavaScript code and written our injected script directly into the page.

Figure 4


DMI[7]=((new DMMenu()).ini("Details.aspx?ID=1101&t="));//--></script><script>alert('XSS_IS_IN_MENU');</script>

As a result of injecting the script we can see it being executed in the user's browser in Figure 5

Figure 5



This would confirm to a malicious user that the application is vulnerable to attack. Now that it has been exposed as being vulnerable, the next steps would be to create an attack that would target potential victims who use the application, wherein we could hijack their sessions, steal their credentials, spoof the content on the site, deface the site, etc.

 

 

Example 2: Company B

 

 

Company B is a very well know software company that provides a wide range of custom controls for use in ASP.NET applications. One of the controls they provide is an rich text editor control. The editor control allows for a wide range of functionality, including formatting text just by clicking some buttons on the control. It allows users to create HTML content, with an additional setting to prevent malicious code from being executed. The benefit of this control, as opposed to the JavaScript menu mentioned above is, this control does not require the developer to turn off the built in .NET validation. As such, we don't have to make our page or application vulnerable to attack just to use the control. This in itself is a good thing, but even good things can be bad sometimes, as seen in the example below.

When initially testing this control I entered a blatantly malicious image tag into it just to see how it would respond. Figure 6 below shows the malicious code that was entered.

Figure 6


After successfully submitting it, I noticed it rendered it back to the page as seen in Figure 7.

Figure 7
%26lt%3bimg src%3d%22%22 onerror%3d%22alert%28%27vulnerable to XSS%21%27%29%22%26gt%3b

Based on what we see in the response, we can make the obvious determination that it is URL encoding the malicious characters we supplied. Now that we know it's URL encoding the values, let's try passing it the same script only this time we will URL encode it ourselves, as seen in Figure 8.

Figure 8
%3cimg src%3d%22%22 onerror%3d%22alert('vulnerable+to+XSS!')%22%3e

Figure 9 shows how the control responded to the URL encoded attack vector we entered.

Figure 9


It appears to have rendered the contents exactly as we entered it, but looking at the source of the page we can see it actually modified it, as seen in Figure 10.

Figure 10

%253cimg src%253d%2522%2522 onerror%253d%2522alert%28%27vulnerable%2bto%2bXSS%21%27%29%2522%253e

We can see from this response that it has modified the request by encoding all the "%" percent signs to %25 respectively. So %3c becomes %253c. Now that we know this we can attempt to prevent it. Using a browser add-on such as Tamper IE we can intercept the request and modify it by removing the "25" from all of the encoded "%25" values, thus forcing it to pass the URL encoded value as we had initially intended, as seen in Figure 11.

Figure 11


After removing all of the "25" values from the encoded string and submitting the request back to the server, we see in the response that our attack vector actually worked and the code ends up being executed in the user's browser, as seen in Figure 12 below.

Figure 12


This is an extremely bad situation. Why? Because we have taken an otherwise secure page, one with the built in validation turned on, and by placing this control on the page have caused it to become vulnerable to attack. Simply by using this control we have sacrificed the security of our application.

 

As you've seen in the two examples provided above we have used 3rd party software that has resulted in us compromising the security of our application. One example, by it's very implementation, requires the developer to turn off the built in .NET validation process. The other, through it's ineffective use of encoding, has allowed the built in .NET validation process to be bypassed. Both of these situations result in an insecure application. So the question becomes, would the application have been more secure if the 3rd party controls were never used? We don't know, but we do know that these security issues occurred as a direct result of using these 3rd party controls. In the end, we as developers, must ensure that the 3rd party software we are implementing will not cause any adverse security issues in our applications as a direct result of their usage.

 

Learn more about managing information technology and programming through online schooling.

Feedback Comments

Feedback

SharePoint Web Parts


All Data Springs Web Parts Support WSS 3.0, SharePoint 2007, and SharePoint 2010 Frameworks

Please select license option for each web part you wish to purchase. We highly recommend the SharePoint Bundle to get all Data Springs Web Parts for maximum value!

 

 

      
Cart


Data Springs Sharepoint Bundle

Best Value! The Bundle gives you all 5 web parts in one package at a very attractive price! Best Value! We think you will be very happy with the SharePoint bundle and great price discounts you will receive. With your purchase all of the web parts below will be included.
 
 
 
 

Random Image Web Part

With Random Image for Sharepoint 2007, you can select multiple images to display randomly when the web part loads...
 
 
 
 

Stock Quote Web Part

Giving your site visitors relevant information is critical. With the Data Springs Stock Web Part you can provide your users with up to date financial information
 
 
 
 

Dynamic Image Rotator Web Part

Who would have thought? Adobe Flash® with Sharepoint! The FIRST and ONLY image rotation web part for Sharepoint using Flash Technology from Adobe! The Dynamic Image Rotator displays selected images and then rotates between the images. Several extended and optional features allow you to select the time to rotate each image, fade between
 
 
 
 

SharePoint Charts Web Part

The MOSS Chart Web Part is a web part built by Data Springs for the purpose of rendering several chart types based on data from a SharePoint list on a MOSS 2007 or WSS 3.0 Site
 
 
 
 

Dynamic News Ticker Web Part

Provide current news items with a user-friendly news ticker for your Sharepoint Portal. With millions of web sites offering information you need a fun way to display information and the solution is Flash News Ticker....
 
 
 
 

Tailored Text Web Part

 Tailored Text Web Part allows you to add text/html to your web site that can be different for anonymous users, registered users,  and even individual users specifically.

 
 
 
 

Dynamic Views Web Part

Dynamic Views is an excellent tool to:
Personalization allows you to go the extra mile in communicating or connecting one to one with your clients. When it comes to technology and web site content, you now have the power to leverage this personalization directly with your users on your DotNetNuke® site

 
 
 
 

Dynamic Login Web Part

Your site content isn't vanilla, so why is your portal's login?

Add pizazz and functionality with Dynamic Login! Use custom templates, localization, redirection rules for various roles and many more features!
 
 
 
 


 
 

Join our mailing list...

Get current news and events the easy way
 
 
   
Subscribe Me

Recent Blogs...

 
Copyright 2005 - 2011 by Data Springs, Inc.