The Skytech Security Fiasco

There was a story making the rounds today on the twitter about a Montreal university student who had been expelled for, ostensibly, testing the security of a web site. If you missed it there are a number of articles out there about it as it has become a bit of a media darling.

The story goes that this young fellow was working on an app for letting students access their data. In order to test their app they were given access to a test server at Skytech, the company behind the student information software. While playing around he discovered an exploit which allowed him to gain access to information on any student. It is a pretty common exploit: not cleaning your inputs.  Al-Khabaz did the right thing in reporting the vulnerability and, to their credit, Skytech had a fix deployed in about a day. This is a bit slow in my mind for such a serious exploit but many company aren’t quite there yet on being able to deploy at the drop of a hat.

A few days later Al-Khabaz ran a security testing tool against the test server he had been given to ensure that there were no other vulnerabilities. This is where things start to go off the rails. Skytech noticed an increased load and claim that the attack was damaging their ability to serve their customers. The president of Skytech, Edouard Taza, called up Al-Khabaz and demanded that he come into the Skytech office and sign a non-disclosure agreement or they would press charges. BullyIt seems that Dawson College got wind of all this activity and started their own investigation. They convened a pannel of 15 computer science professors who voted to expel Al-Khabaz.

That brings us to today. I see a number of things here which could have been done better both from a technical and from a human relations point of view:

  1. There is no denying it Al-Khabaz should have checked with Skytech before running vulnerability tests. I can see where he is coming from and it is unlikely that he knew how much traffic the tool, Acunetix, would generate on Skytech’s site.

  2. There is no way that Acunetix, running on a single developer workstation, should be able to take out a website designed to serve such a large body as all the students in Quebec. There is a lack of preparedness for attacks on Skytech’s part. This is a site which is likely to attract attacks as it contains a lot of student data including SIN numbers, grades, addresses and the like. One thing is for sure now that Skytech’s ineptitude has been revealed they’re going to be the brunt of some actually serious attacks. If you’re a student in Quebec you should be worried.

  3. An attack on a testing server should not have had an effect on the production site. It is a test server for a reason, you test things against it and, from time to time, that testing is going to be destructive. Separate your servers!  With the low prices of cloud servers there is no excuse to have your test site on your production hardware.

  4. Skytech reacted well to the first vulnerability but they reacted terribly to the proceeding attacks. As a company you have to know that threatening students with legal action is basically blackmail. If you want people to keep quiet about how crummy your security is then you’re pretty much going about it the right way. If you want to actually be secure then you’re screwing up.  Believe me having a whitehat test your site and report problems is going to save you some big trouble in the future. That’s why Google run competitions to find exploits in Chrome.

Now I understand that Skytech have made some moves to fix their screw-ups here including giving Al-Khabaz a scholarship and offering him a job. Good for them. I don’t believe he took the job but I wouldn’t either, who wants to work for bullies?

  1. From what I can tell Skytech were getting a free app created here by students of Dawson. So there was probably some sort of an agreement between Dawson and Skytech to allow students access to a real world system in return for an app. Sounds a lot like slave labour to me. I’m not a fan of unpaid internships or free collaborations. Companies should pay for apps to be developed for them. Programmers should not be giving services away for free to companies, it devalues the profession. If you’re a programmer and you want to hack on something to help people there is a whole lot of open government data out there which has a greater potential than Skytech’s data.

  2. Dawson college are so far into the wrong that they can’t be saved. To me the fact that 15 researchers chose to slam the research of a student and in fact expel him is crazy to me. They claim that it is against professional conduct. Okay fine, point me to the accredited document which outlines the professional conduct for a computer scientist. No, no I’ll wait.


Even if such a document existed testing the security of a test server is unlikely to be a serious violation. The CBC checked with some lawyers and they could find no charge under the criminal code so it is radically presumptive of the university to suppose that the activities were illegal.

The kangaroo courts that universities set up in this country need to be stopped. These professors, locked in their ivory towers, have no idea about real world consequences. Where are the police charges if Al-Khabaz actually did something seriously wrong?

I know that if I were a student I wouldn’t want to go to Dawson College and if I were an employer I would be suspicious of graduates of Dawson. If their professors can’t understand the difference between criminal hacking and harmless testing they shouldn’t be teaching and their students might need remedial training.

Dawson saw this as an optics problem and did what they could to get rid of it. Well that worked out pretty well didn’t it, Dawson?


Content Security Policy for MVC

In the last article we talked a bit about Content Security Policy. Now let’s see how to quickly apply it to an MVC project.

The MVC project have provided some extension points in the lifecycle of a request which allow you to hook in almost as if you’re using AOP.  The one we’re interested in today is the global action filter. This is fired for every request and is an ideal place to put in a hook for adding HTTP headers.

First we create an action filter attribute which extends ActionFilterAttribute

As you can see here I’ve put in all the different headers we talked about yesterday. You could make this more efficient by checking the browser and only sending the response which suits. That is kind of a pain to do as CSP is still in flux on most browsers. In a couple of years you will probably be able to only send one header.

Next we tie it into MVC. You can throw it into the FilterConfig.cs file like so:

(line 6 is the relevant one)

And you’re done!  I tested it by throwing in an inline alert(‘hi’) and found it to be effective. Well effective in Chrome and FireFox. IE10 still merrily threw up an alert. IE10 support is not there yet, perhaps in IE11.

There is one other good way to add CSP to an MVC project and we’ll cover that in a future post.

Content Security Policy

A few weeks ago I was doing some research into web application security to placate some security concerns a security audit raised. For the most part what I found was the typical advice

  • Avoid SQL injection attacks by using parameterized queries
  • Use low privilege accounts to run the web server and the database
  • Don’t connect to the SQL server with an account with permissions other than dbreader and dbwriter(or your database’s equivalent)
  • Validate user input
  • HTML encode any untrusted string(so pretty much everything)
  • Avoid using dynamic SQL

One relatively new development I hadn’t heard of was using a technique called Content Security Policy. To understand the purpose of CSP you first need to know a little bit about what comes down the line to you from the web server and how the browser handles it.

For many years, until Chrome came a long a messed it all up, the first 7 characters of every URL you saw was http://. This was a protocol identifier just like ftp:// or smb://. Chrome dropped showing it, something I agree with entirely. The protocol HTTP is the language which web servers speak. One of the things which HTTP defines are things called headers. These headers provide meta-information related to the request or the response. For the most part you can be a web developer and never look at HTTP headers. It is the headers which contain POST parameters as well as Accept-Types and Content-Types. The body of the HTTP response contains the HTML, CSS and JavaScript which define the page. Within that markup you can define external resources to load be they images, scripts or style sheets.

CSP is another header which describes the behaviour of the browser when it comes to loading the external resources and processing internal scripts. There is a wide variety of things which can be done using CSP but the most useful is to block the execution of inline JavaScript.


How is my JavaScript going to get run if I can’t have it inlined? Well pretty simply you make all of your javascript included from external files.


Because one of the most common attacks against sites it to inject some nefarious JavaScript in a way that it is rendered out when other users are logged in. By doing so you can grap their cookie information or information on the page. Think about a site with a comment system, if a bad guy injects some javascript code which can run in the context of other users then they can perform any action that the logged in user can. If all your JavaScript comes from static JavaScript files then there is no attack vector to exploit.

To get this working you’re going to need to add 3 different headers to your site. This is because the various browsers have differing levels of support for CSP.

Content-Security-Policy: script-src 'self'  
X-WebKit-CSP: script-src 'self'  
X-Content-Security-Policy: script-src 'self'  

The first line is the policy as defined by the W3 standard, it is supported only by chrome and even then only by version 25+. The second version works in older WebKit based browsers. The third is supported by FireFox and IE10+. The support for CSP across browsers is not fantastic. At the time of writing there is support for about 55% of users.

There are quite a few rules you can use in the CSP. The rules above require that all your scripts come from your domain. If you make use of a CDN then you can add it to the end of the rules

Content-Security-Policy: script-src 'self'  
X-WebKit-CSP: script-src 'self'  
X-Content-Security-Policy: script-src 'self'```

You can also set the default so that all resources (scripts, style, images, flash, frames, fonts) are restricted to your server.

Content-Security-Policy: default-src 'self'
X-WebKit-CSP: default-src 'self'
X-Content-Security-Policy: default-src 'self'```

Once you get your head around not being able to use inline JavaScript then CSP is a clear win and should probably be the default when you create a new project.