Sasha Sydoruk

This is just great. You can now hack websites with XSS in PDF files. Adobe Reader will executed any JavaScript passed to it through a query string. Here is a working example:

http://www.example.com/document.pdf#whatever_name_you_want=javascript:alert(document.cookie);

If you replace www.example.com and document.pdf with valid samples and click on the link, the browser will pop up, load the specified file from the specified site and show you your cookies for that site.

Adobe Reader v8.0 is not affected. Also, this does not work on some Win XP SP2 + IE 7.0 systems.

Found via Alek Levin.

If you have a console application that creates a console for IO, make sure that the application has unrestricted UI permission.

If you execute your console application in Internet_Zone code group and receive a security exception, you have 2 options:
1. provide unrestricted UI permission to the application
2. get your application to execute in LocalIntranet_Zone code group.

More information

Today I was working with a solution that had 2 console applications. Console application A was creating a child application domain and executing the console application B in the child domain. Console application A had a project reference to console application B.

Everything worked until I decided to turn down code access security in the assembly that is being executed. Properties -> Security -> Enable ClickOnce Security Settings. Select “This is a partial trust application”. For ClickOnce Security Permissions pick “Internet” zone.

Now, when I try to rebuild the solutions I get this - Could not find file ‘Microsoft.Windows.CommonLanguageRuntime, Version=2.0.50727.0′.

To resolve this problem you have to uncheck “Enable ClickOnce Security Settings”. Once you do it, you will be able to rebuild your solution.

But what if you want to keep your ClickOnce security settings? Make sure you reference your assembly B as a file and not as the project.

While preparing for 70-536 I finally approached the topic of code access security and, just like I feared, it is not easy. No wonder it didn’t get the wide adoption that Microsoft hoped for. CAS does not fall into pit of success. It is much easier to do the wrong thing as opposed to being very easy to do the right thing.

While looking for more info on CAS I found this good post that clarified some of the things for me. Maybe it will help you as well.

SQL injection is a very dangerous thing. An experienced hacker can break your site open in the matter of minutes, if the SQL injection opportunity exists. To demonstrate how quickly things can happen watch this video:

[youtube]MJNJjh4jORY[/youtube]

As you can see, once the hole has been found, you application is fully open to data theft and vandalism.

What is the best way to prevent SQL injection? Never and I repeat never, concatenate together your SQL queries. One common mistake that I see quite often – “We are safe because we are using stored procedures”, but when you look inside that stored procedure you see the same string concatenation; usually this concatenation happens with ordering and sorting clauses. It is very important to realize that you are still vulnerable even if you concatenate your strings in the stored procedures.

What is the right way to do it? Use SqlParameters or any other implementation of IDataParameter that works with your database. So, instead of this:

string sqlBadQuery = “SELECT * FROM User WHERE FirstName = ‘” + tbxFirstName.Text + “‘”;

use this:

SqlParameter spFirstName = new SqlParameter(“@FirstName”, SqlDbType.VarChar, 50);
spFirstName.Value = tbxFirstName.Text;
string sqlQuery = “SELECT * FROM User WHERE FirstName = @FirstName”;

In this example we created SqlParameter spFirstName. In the constructor we are providing the name, data type and length of the parameter. Notice that because we specified the data type as VarChar, we didn’t have to use single quotes in our query. SQL Server will do it for us.

A couple of times I was told that even when you use parameters, you are still vulnerable to SQL injection. I am not sure how correct this statement is. I looked for supporting information and I could not find anything. When you execute an inline, parameterized query in SQL Server with profiler running you will notice that this call is handled by sp_executesql. sp_executesql provides the same benefits as stored procedure does – security and execution plan caching. So, even if you pass some bad input like this – “’ or 1 = 1 –”, it will be properly enquoted and 0 rows will be found. To find out more about sp_executesql - go here.

Now, if you have stored procedures available, by all means use them. But sometimes you just have to revert to dynamic SQL, and when you do, make sure you use it correctly. Here is a really good article by Erland Sommarskog - The Curse and Blessings of Dynamic SQL. This article describes in a great detail why you would use dynamic SQL and how to do it in a safe manner.

Wikipedia has a really good description of what a SQL Injection is. You can find it here. Also here is a general list of links that discuss the issue and the remedies to SQL Injection:

• http://www.unixwiz.net/techtips/sql-injection.html
• http://www.spidynamics.com/papers/SQLInjectionWhitePaper.pdf
• http://www.ngssoftware.com/papers/advanced_sql_injection.pdf