Google
 
Showing posts with label Ajax. Show all posts
Showing posts with label Ajax. Show all posts

Thursday, August 21, 2014

Code disclosure pattern issue with AjaxControlToolkit

I was helping a team troubleshooting some issues found when they ran IBM Security AppScan tool against a web application.
One of the issues reported by the tool was:

Web Application Source Code Disclosure Pattern Found

Severity: Medium
URL: URL/ScriptResource.axd
Entity: ScriptResource.axd (Page)
Risk: It is possible to retrieve the source code of server-side scripts, which may expose the application logic and other sensitive information such as usernames and passwords
Causes:
Latest patches or hotfixes for 3rd. party products were not installed
Temporary files were left in production environment
Debugging information was left by the programmer in web pages
Fix: Remove source code files from your web-server and apply any relevant patches


And the report included the following sample response:
// Add common toolkit scripts here. To consume the scripts on a control add
//
//[RequiredScript(typeof(CommonToolkitScripts))]
//public class SomeExtender : ...
//
// to the controls extender class declaration.

So the highlighted part indicated to appscan that the application exposed some code. And as I have previous experience with AjaxControlToolkit I could give the proper advice.

Referring to the source code of AjaxControlToolkit, you can find that the file Common/Common.debug.js includes the above lines as a hint to developers. So it sounds harmless, another false positive, and we can live with it, right?
Probably not. The release version of the above file Common/Common.js does not include any of this C# code. This is an indicator that a debug version is being used in the test. What started as a security issue, is now a performance issue, and using release build should fix it.

In general, automated security, code analysis, or performance testing tools generate false positives, but they should not be ignored without proper analysis.

Note: the latest version of AjaxControlToolkit includes the commented hints in the Client/MicrosoftAjax.Extended/Common/Common.pre.js file

Monday, March 8, 2010

Changing AJAXtoolkit:CalendarExtender day format

AJAX toolkit has a set of awesome controls, and very customizable too. But one property that is not customizable OOB is how the day names are displayed in the Calendar extender.
The displayed format is two letters only. But what if you want it to be displayed in three letters?
Here a small cosmetic surgery (i.e. code changes).










BeforeAfter



So, what does it take to do it successfully?
I opened CalendarBehavior.debug.js, which contains the debug version of the extender's JavaScript. Day names were obtained from an array named: dtf.ShortestDayNames:

dayCell.appendChild(document.createTextNode(dtf.ShortestDayNames[(i + firstDayOfWeek) % 7]));

Searching the library code, I found that this array is defined in MicrosoftAjax.debug.js. as:

ShortestDayNames":["Su","Mo","Tu","We","Th","Fr","Sa"]

And fortunately, another array was defined with three letters names:

AbbreviatedDayNames":["Sun","Mon","Tue","Wed","Thu","Fri","Sat"]

So all what it takes is to replace ShortestDayNames with AbbreviatedDayNames in both CalendarBehavior.debug.js and CalendarBehavior.js:

dayCell.appendChild(document.createTextNode(dtf.AbbreviatedDayNames[(i + firstDayOfWeek) % 7]));

And build.

It's great to have the source between your hands :)