November 2006 - Posts
I found it useful to do some check with IIS when conducting security deployment inspection
From http://support.microsoft.com/default.aspx/kb/326965:
SYMPTOMS
When you request a file from an IIS 6.0 Web server, and the file has a file name extension that is not a defined MIME type on the Web server, you receive the following error message:
HTTP Error 404 - File or directory not found.
and then:
RESOLUTION...
It might look like it is a problem but it is just another countermeasure against possible attacks. IIS 6.0 does not serve unregistered file extensions. With IIS 5.0 files with unregistered extensions would be served for download.
Imagine situation that admin changes web.config file but saves the original one with .old extension. With IIS 5.0 attacker could navigate to it directly like this www.mysite.com/web.config.old. The result would be web.config.old handed to the attacker without any restrictions.
Since .old is not registered with IIS 6.0 and there are no wildcard chars by default [which is not the case with IIS 5.0/5.1] IIS 6.0 would return 404 for above request.
If you use non standard .Net files like .ini, .old, .bak I'd recommend:
- Do not do it. Do not deploy unnecessary files.
- If you have to, then protect it in your web.config using HttpForbiddenHandler
- If you use IIS 5.0 [Win2k] - isn't it time to move on?
- If you use IIS 6.0 - beware when applying wildcard characters MIME mappings in IIS' metabase
Cheers
OK, we see more and more awareness for importance of secure coding. There are even developers that implement Best Practices for secure coding. But here we are - there is new area to dig into - mobile devices. Turns out there will be about 800 millions of workers powerd with mobile devices by 2009. And there are some studies that unveal the gap between the IT folks who understand the risks andthe management that sees only benefits of using such devices. More on that here. More risks, more targets to attack ... and protect
Following Ohad's post regarding the subject I'd like to present it from some different perspective...
Imagine you provide search criteria as follows:
"Initial Catalog" - try it. What do you see?
More like these here
Doesn't it make you want to write more secure code? :-)
Yesterday I had an honor to present MS's vision and offerings regarding Security Development Lifecycle - in MS products and our recommendation for Security Engineering when developing application using MS technologies.
COMSEC was hosting the event.
.gif)
We also announced our partnership in this space.
We also announced ACE Israel team launch. ACE [Application Consulting and Engineering] team is corp based team focused on application security for MS apps such as microsoft.com, msn.com, and hundreds of internal like HR, CRM apps. Recently ACE started providing its services to Microsoft's clients. ACE team provides comprehensive security engineering services around application security - called SDL-IT. The services include:
- Workshops
- Application Security Assessments
- Threat modeling
- Establishing Application Security Processes inside organization
In my previous post [part I] I've showed why it is important to do server side input validation and how easy it is to by pass any client side input validations for web services invocation scenarios. Actually anything that utilizes HTTP is pretty easy to intercept and change on the client - classic Web UI, Web Service, and AJAX. One can use http debugging/proxy tools like fiddler. I show this demo to folks and sometimes I hear "Hey it is not relevant to us - we are using Remoting over TCP channel, we are safe - it is binary encoded". I must agree that I had some hard times to find the tool that does interception for remoting traffic - I did not find it so I decided to write one for proof of the concept. Luckily remoting offers rich interception functionality - called sinks. I utilized this and created such interceptor. So watch the video. Double click it to see it in full screen mode.
Sorry for the bad quality - needed to cut the movie and reduce the quality to make the file smaller.
Make sure you do input validation on the server next time - not on the client. Unless you do not care for security...
Next demo to come is for WCF... will take some time but it will come
It is nothing to do with fishing rather it is kind of cyber crime that exploits today's technology inability to clearly present to end user the identity of the web site she navigates to. It also relies heavily on human naive nature. Yeah, yeah - the yellow lock in the bottom of the browser [IE 6] and even next to URL [IE7]. But did you actually clicked it and checked the actual certificate it uses? Did you verify that it's CA is well known trusted authority.
Huh?...
Consider this. I got one day email that sounded very official from one agency [although I am not their customer]. It looked like this:
Note that the URL is OK, but underlying ACTUAL URL is funny, isn't it? It took me to the well designed web site - total spoof of the original one telling me I need to authenticate and provide my creds. I did not submit any since I am not the member but I suspect someone else would - resulting in her identity loss.
Today's browsers provide anti phishing capabilities but it is long road ahead to make it work good. Mean while tell your grand mom to watch it out when she goes shopping on the net.
Cheers
Some time ago I was reviewing high level arch spec for really big project. in one place it stated "Input validation checks will be done on the client side for perf reason. Since client part will do the security checks the server part will not performs input validation since it is redundant and may hurt the performance"
Huh?....
Watch the video to see what happens when the input is validated on the client only. Double click it to see it in full screen mode.
This time it is WinForms client talking to Web Service. Next time it is Remoting client talks to remoting listener. The result is the same.Wait and see it in the next post
I was pretty confident with my English knowledge. I think people always seem to understand me and I think I almost always understood what they wanted from me. This confidence was recently shaken by Seattle times article "A first look at Vista, good and bad". Can you help me with logic here? I am having hard times to understand why these are bad.
THE BAD
Security
It's vastly improved, but at times that's going to make the software frustrating to use. It could be especially frustrating shortly after Vista is released, if other software companies haven't updated their applications to work smoothly with Vista's more restrictive settings.
A cornerstone of Vista's security is User Account Control. What this does is make it easier to run the system in a restricted mode. Users in restricted mode don't have authority to do things like download new programs. This prevents attacks from taking over a PC. When users want to change settings or download a program, a window pops up and asks if the user wants to invoke administrative privileges and proceed.
The system can also ask for the administrator password, so children can't override parental controls, for instance.
Microsoft has been fine-tuning the system to minimize the pop-up privilege requests, but this feature is likely to interrupt users more than they'd like. It's probably a small price to pay for improved security.