Function1

By now, you’re probably aware that “Patch 2″ was released last month for ALI 6.1 MP1, and that it addresses a “security vulnerability”.  Specifically, this is a Cross-Site Scripting vulnerability that is patched by swapping out a single file (uiinfrastructure.dll), so it’s pretty easy to apply the patch if you already have 6.1 MP1 installed. Note: there’s also a patch for a similar vulnerability in Collaboration Server, so check that one out too!

For obvious reasons, I won’t call out what the exact vulnerability is, but I did want to mention it as a reminder to those of us that code custom applications.  These vulnerabilities don’t just affect major enterprise applications like AquaLogic Interaction.  They can – and probably more often do – affect our own custom code.

In a nutshell, Cross-Site Scripting (XSS) vulnerabilities exist when someone can put some text into a URL, and have that text appear as un-encoded HTML in the resulting web page.  The reason this is a vulnerability is that someone can craft a URL that has malicious Javascript in it; the Javascript then runs in the security context of the web site you’re running.  Obviously this is a problem because JavaScript’s powerful enough to do some pretty nasty things, like stealing your session cookie and transmitting it off to a third party so they impersonate your session.

Another big vulnerability that people often fall prey to is a SQL Injection attack.  Like XSS, it depends on text from a URL crafted by a malicious third party, but in this case that text ends up in an SQL statement.  For example, suppose you have a line of code that reads:

SQL = "select * from USERS where USERID=" + Request.GetParameter("uid");

See how the userid is coming from the query string?  What if someone then put this in the query string for “uid”:

"1; drop table USERS;".

Then, the SQL statement that would end up running against the database with the right credentials would be:

select * from USERS where USERID=1; drop table USERS;

See how this can be a big problem?  Someone just wiped out your user table!

So, bottom line:  when you’re writing code:

1. Make sure nothing in the URL gets inserted directly in the HTML without being scrubbed of HTML tags or encoded first (the ALI vulnerability actually does encode the string in question, which mitigates the vulnerability significantly).

2. Make sure nothing in the URL ends up in SQL strings without being encoded first, or better yet, use prepared statements to make sure arbitrary SQL commands can’t be created in the first place!