Reposted from Performance Gain - Security Risk

Good intention for better performance may lead to flawed design and bring in more security risks.

Consider the following ASPX page:

Here is why it cannot be accessed:

When trying to navigate there you get:

Great, love URL authorization!!

Now let's examine another ASPX page:

When navigating to this page you surprisingly get this:

The reason for that is when using Server.Transfer the request to the second page does not go through the whole ASP.NET pipeline which includes URL Authorization module

Security part is here http://msdn2.microsoft.com/en-us/library/ms998375.aspx

Performance part is here http://msdn2.microsoft.com/en-us/library/ms998549.aspx 

Performance and Security has never been good friends - fortunately we have J.D. who is bridging the two letting us enjoy both.

Enjoy

In my previous post, Code Inspection - First Look For What To Look For, I've described how to look for sensitive data and hints in the compiled assemblies. The other challenge I was looking to solve is boosting my productivity. So with little magic of scripting (more magic here Scriptomania - Scripting Tools and Utilities) and generous help from my friend DIR (more here Security Deployment Inspection Using Office.) I've accomplished task of scanning all directories, and dumping all the strings into text files, like this:

All I had to do is go over each and every text file and look for funny things (depicted in Code Inspection - First Look For What To Look For). Pretty annoying: double click, scroll down, move to "Seen" folder - no marking and categorization or follow up capabilities - WAIT A MINUTE!!! Does not it sound like Outlook? So I dragged all the text files into my new shiny Outlook 2007 getting all the goodies it provides:

1. Move through items using up and down arrow using left hand.

2. Scroll the text in preview pane using mouse wheel by right hand.

3. Tag and categorize.

4. Everything else Outlook provides.

5. AND OF COURSE USING INSTANT SEARCH IS A REAL PLEASURE:

Enjoy

Reposted from XSS? - Do not Make Me Laugh, We Use WinForms

I find myself sometimes (actually too many times...) in situation explaining people of impact of Cross Site Scripting (attack) attacks as a result of importer encoding of user input (vulnerability) and how to counter this attack properly. Once all parties understand this everybody feels great relief since "our app is not web app - we use WinForms". Great!! The threat is mitigated by removing the feature of rendering HTML output...

"Hold it, you told me that your system presents to end user different types of documents, right?"

"Right, so?"

"Do you show HTML docs too?"

"Sure!"

"Great, and what do you use for it?"

"WebBrowser control, of course"

"I get it... So if you get HTML doc, it might include some script like this one:

<script>alert("HACKED!!")</script>

 that can render as follows, right?"

"... right..."

How one prevents scripts running inside the WebBrowser control?

I did not find an easy way to control it other than using PINVOKE described here -  http://msdn.microsoft.com/workshop/browser/hosting/wbcustomization.asp?frame=true Here is another post on that one - http://slingkid.blogsome.com/2006/05/26/ (that actually points back to the above link but has good interop example) and another discussion here -  http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=66493&SiteID=1

Cheers