I’ve been using windows 7 since the first day the beta version was out publically, after that I moved to the RC version and now I am using the RTM version. To be honest I am completely admiring it, despite some bugs I’ve noticed on the beta version here and here, and a problem caused by my graphics card here, I still admire it..
Two (2) days ago, I got a genuine 64 bits Windows 7 Professional copy, I installed it yesterday and every thing, including drivers, worked automatically with a little update of the graphics drivers. Despite the fact that it is a 64 bit version, all the programs (most of them are 32 bit) are working normally. Now Windows 7 is my main system after all this period of testing (I erased Vista completely from the HDD).
Note : If you are a student Windows 7 Professional is available for free to the MSDN AA subscribers, if your university / college do not offer MSDN AA account for it’s students you can get Win7 for $30 [link]
This post was aimed to talk about the XP mode, but first I want to mention some reactions from some guys out there claiming that Windows 7 “sucks”, or it is just “a Vista with improved graphics”.
First, someone mentioned that after using Windows 7 for 5 minutes (or 2 hours) he switched back directly to *Linux*, well, no comment, I only say : “take a deep breath, and forget your hurt feelings towards Microsoft for a while, then try Windows 7 again, just admit they are doing great software these days”.
Someone else said : all the programs he run were not compatible with windows 7, I am completely astonished by this, for almost 10 months now, from the beta to the RTM version, I never encountered a software incompatibility on Win7 yet ( the 32 bits or the 64 bits), so in this case, there are two possibilities :

1. You are running a program from 1703 : if so… ask yourself : do you seriously want to keep running that thing? wouldn’t you consider upgrading it or such? If the answer is no, keep reading, the XP mode might save you.
2. You never heard about the “Compatibility Mode” introduced years ago, within Win 7 or Vista you can choose which environment the program works (or supposed to work) normally, here is a sample screenshot about that, just right click your program to see this:  As you see, you can even specify Windows 95, or even the service pack in case of Win XP, 2003 and Vista. Of course Windows 7 is far smarter than this, if it detects that the program is too recent it propose also Windows 2008 and do not allow versions older than XP.

If after all this, your program still doesn’t work (which is not likely to happen) then running XP virtualized programs is your end line solution.

Windows XP mode :

Windows XP mode allows you to run programs within an XP virtualized environment directly from you Windows 7 desktop, I will show my experience installing it and how to quickly make it runs on your computer, although I think I will never need someday.

Windows Virtual PC provides the capability to run multiple Windows environments such as Windows XP Mode from your Windows 7 desktop.

In order to install the Windows XP mode on your computer (which mean get a valid free copy of windows XP virtualized on your pc :) ) you need to have a CPU that supports virtualization, most of recent hardware support that!

Windows Virtual PC requires a CPU with the Intel® Virtualization Technology or AMD-V™ feature turned on. This feature must be enabled in the system BIOS. For details on how to enable, visit the Configure BIOS page or check with your computer manufacturer.

I have an AMD Turion 64x2 CPU, and I used this tool called AMD-V Hyper-V Compatibility Check Utility to test that the CPU is compatible, for Intel CPUs you can use the Intel Processor Identification Utility for this.
Running this utility will show if the CPU you are using support the XP mode or not, and whether the hardware virtualization is enabled in your BIOS or not. For me the CPU is compatible, but virtualization was disabled, so I enabled it in the BIOS as shown bellow :

Once this is done, you run the utility again, and that is what I got :

Now you go here http://www.microsoft.com/windows/virtual-pc/download.aspx and download the Virtual PC and the Windows XP mode, be sure to choose the best system type, 32 bits or 64 bits.
After installing it, you should get Windows Virtual PC menu like this in the start menu :
Starting the Windows X mode, will bring some wizards to configure the virtualized XP machine, also notice that your HDD will be shared between Windows 7 and the virtualized Windows XP, so that you can easily install programs from there.

Now let’s suppose Notepad++ didn’t work on Windows 7, what we have to do is install it inside Windows XP like follows :
If you turn back to windows 7 start menu now, you can find the newly installed program on windows XP there, you can pin it to the task bar or create a shortcut to the desktop and run it like any other program under windows 7, the window borders will show that it is running on the XP mode:
And here is the result :

As you can see, it is running pretty well like any other program on 7 except that it is on a windows XP, and because it has access to the whole filesystem, you will not notice any difference. Another time, you might never need this someday, this might be handy for companies who *do not* want to upgrade IE 6 for example.
So if after all this, some guys still say “we tried it for 5 mins and no program worked in it” then just know they might have serious psychological problems with the word “Microsoft”.

XSS is the web vulnerability number 1 according to the OWASP project. If you developed web applications before, you know that its prevention exceeds escaping characters and using some regular expressions to filter out user input.

A good video here, show in 40 minutes XSS and why it’s more dangerous than what most of us think, check it out to understand what XSS is, although it explains only the XSS in the browser and not injected JavaScript like in PDF files or vulnerabilities in QuickTime and other software.

The best way to prevent XSS is to take advantage of the platform you are developing upon. Symphony has a built in functionalities to prevent XSS and CSRF. Today I will show a sneak preview of how the ASP.NET framework protect you from XSS attacks, this functionality has been around years before.

By default trying to inject a script in an ASP.NET form will trigger the exception System.Web.HttpRequestValidationException, as follows :

Although this protect you from XSS attacks but it shows your users an ugly exception and even some information that might be sensitive, for example the path of the page that caused the error and such, to solve this issue there are several solutions that I will show 2 among them.

1. Redirect to the default error page using the Web.config file:

As you maybe know already, you can redirect users to a default error page using only declarative syntax in the web.config file, and this includes also exceptions thrown when XSS attacks are encountered.

In the web.config file, insert this code in the <system.web> section:

<customErrors mode ="On" >
  <error statusCode="500" redirect="error_page_handling_500_status.aspx" />
</customErrors>

For more detailed information about custom errors handling on ASP.NET you can refer here, for example you might want show errors only when connecting to the website remotely etc… You can provide as much error pages as you want mapping the appropriate HTTP error status, in this case we handle the 500 HTTP error code.

2. Override the on errors method and handle manually the response :

This method is more flexible and powerful, since it allows you to handle each exception separately, the only caveat is that you have to send the response HTML to the user yourself, because once an exception is raised, the ASP.NET execution pipeline breaks down. here is a sample of how to do this, in your page inert this code:

protected override void OnError(EventArgs e)
{
    if (Server.GetLastError().GetBaseException() is 
                        System.Web.HttpRequestValidationException)
    {
        Response.Clear();
        Response.Write("<html><body>");
        Response.Write("<h1> Your input has some unauthorized " 
                        + "markup, please provide a valid data </h1>");
        Response.Write("</body></html>");
        Response.StatusCode = 200;
        Response.End();

        //Response.Redirect("default.aspx");
    }
}

Here you can notice that we check if the exception was raised by the detected XSS input, then we clear the response buffer and put some feed back to the user, of course you can send a full HTML page at this stage, and definitely you have to change the HTTP error status to 200 to indicate to the browser (or a JavaScript code using XHR) that the request was executed successfully. 

Also notice the commented line, you can simply redirect the user to anther page, but this is not encouraged because users will have no clue about what happened.

Even normal HTML markup is detected as malicious code what to do?

Despite the flexible protection that the ASP.NET XSS filters provides, some times you need to accept such input from your users (<b> or <i> tags…), and hence, you need to tell ASP.NET not to check for XSS anymore. This is not an advised step and in 90% of the cases you will never need to do this.

To specify a page that doesn’t need XSS protection, you add this attribute to the page

ValidateRequest="false"

From now on, you have to validate yourself the user input, or even the output of data which is coming from outside sources like web services or a database. One step to never forget is escaping data when rendering it back to the user. This line do it nicely :

Server.HtmlEncode(userData);

Escaping data might sound as an ultimate solution to all the XSS problems, but it is not, most of the cases, programmers do not sanitize completely the data that they write to a database, and when displaying the same data, they consider it trusted, since it resides on their database, and this is when persistent XSS take place. So as an advice: never turn off the XSS validation unless you are 100% sure about what you are doing.

An example of this vulnerability can be found on the BlogEngine 1.3.0.0 open source project (tested here http://www.martani.net/2009/02/windows-7-part-3-internet-explorer-8.html), despite the fact that a brilliant team was working behind it, but… never trust user input.

 

user data is malicious unless proven otherwise.