Saturday, 29 September 2012

Error 403 Forbidden when using SSL Url Rewrite

Sadly, there is no neat way in IIS to redirect at http traffic to https. Nowadays, you can achieve this kind of functionality by writing a url rewrite rule into either web.config (for that site only) or applicationhost.config for the whole server. This rule lives under system.webserver and might look something like this:

Once you upload this, the redirect will occur but if you get a 403 error, the reason is that you must set the site to NOT require ssl in IIS. This is under SSL Settings for the web site you are using. If you require this then although you should be rewriting the url, the original request for http will not be allowed to be processed. Simply disable "require ssl" and then the rewrite rule will ensure all requests stay on ssl.

Tuesday, 25 September 2012

Suddenly Getting a 303 error on IIS

I have a site which is configured to use SSL and has a rule in the applicationhost.config to ensure any requests to http are redirected to https.
I then added another site to the box which was basically a copy of the first site and which I was using to test a different database engine. I realised that I couldn't put it under the main site because of all kinds of weird errors so a friend suggested that I add another level of subdomain so I could have and which I could then add as a header to iis to direct to my new site.
The only issue was that the server was configured only to allow ssl and I didn't want to buy another ssl cert for it so I tried to set it up to use the same certificate as the other site. This was the mistake I made since by doing this, it disconnected the certificate from the previous site without telling me.
Examination of the logs (after about 20 minutes when the penny dropped) gave me the clue that a request to port 80 was returning a redirect but then there was no request to port 443 which there should have been for the ssl connection.
All I did was assigned the cert back to the correct site and it was up again. Also, I then created a self-signed certificate for my other test site.

Monday, 24 September 2012

Applying basic sanity to security policies

There are a few pieces of information that I find staggering. I found out today that 1 in 9 people use 1234 as their card PIN and that something crazy like 40% of people use one of 100 passwords. Now, the best way of making things secure is to have some kind of password policy but this is not always desirable because if your site is low risk, you might prefer weaker passwords as opposed to scaring potential users away with high-security. Well at the very least, you should blacklist the top 50 or 100 passwords and simply not let people choose, "password", "password123" etc.
Just because you might hash the passwords does not in itself add a massive level of security as we found from the Linked-In hack. You should salt passwords but only with variable salt so that the hash of two different people's identical password will not be the same in the database. This prevents frequency analysis of the data if it is stolen from your database.

MySQL For SQL Server developers

No doubt there are millions of articles out there that cover the same thing but as per most computer science related topics, we have become so overwhelmed by the topics that I thought I would write another article.
I will update this as I go along but these are some differences I have found between MySql and SQL Server.

  1. Use MySql Workbench, which seems to be the best (well from the free tools) and gives an amount of intellisense= especially useful for learning where to put the semi-colons.
  2. The types are different. This might be obvious but although the main types are the same, like integer and varchar, there are also types that are not in both languages so be careful. Of special note is BIT which is a boolean in SQL Server but is more like CHAR in MySql, use BOOLEAN instead which takes 1 or 0.
  3. You can only use literal values for defaults, not functions. For this reason, if you want something like the current date/time, you can either use a TIMESTAMP field and the CURRENT_TIMESTAMP default (which only works for the first timestamp field!) or you need a trigger.
  4. getdate() is NOW() in MySql
  5. Lots of methods are in both languages but some have different names and parameter positions such as DATE_ADD instead of DATEADD.
  6. MySql is not clever enough to work out where a store procedure starts and finishes. For this reason, you have to write DELIMITER $$, or some other random set of characters, before CREATE PROCEDURE (not PROC) and then at the very end of the proc, after END, you put the characters like this: END$$ and then another line that changes the delimiter back to ;
  7. Parameters in MySql cannot have @s on them, they are normal cased words. If you get a conflict with a column name, you can use back ticks (') to delimit the parameters in a similar way to square brackets in SQL Server.
  8. Local variable declares in stored procs must all be the first statements after BEGIN. There is also a precedence in the types of DECLARES which must come first - Google will help you with specifics.
  9. You must put a semi-colon after every statement. In SQL Server, the interpreter can usually work out where statements start and end.
  10. You call stored procedures by using CALL StoredProcName(); and not exec
  11. You cannot use RETURN in a stored proc, you can implement it by using LEAVE
  12. Encryption is much more basic. Although they have ENCRYPT_AES like ENCRYPTBYKEY(), it only supports 128bit keys (without rebuilding the source) and does not support the authenticator functionality. Also, these are by password and don't support keys as primitive types.
  13. UUID() is not guaranteed to be unique! Kind of defeats the point.

Thursday, 20 September 2012

Why git is loved and loathed

If you ask people what they use for source control, they will either say, "subversion/sourcesafe/TFS" or, "you need to use git because it's amazing". I have approached git several times now and still find it, for the most part, impenetrable. No doubt, I will open a can of worms with this post but this is my take on git - from the perspective of someone who knows how to write, php, C, C++ and Java under Windows and Linux.

  1. I don't dispute that git is powerful and fast, presumably there are no problems with the underlying technology working properly - i.e. it is technically reliable.
  2. The fact it is a distributed model does take time to get used to but this is not the reason why I and others find it hard to install and use.
  3. The use of github and gitolite to run repos does not help in understanding the model which is supposed to be distributed but which github etc seem to imply is actually client-server. The use of these tools is not explained well - although I saw one useful comment which said these are primarily to allow more fine-grained security setup.
  4. The tutorials seem to be mostly theoretical/over-simplified. Every time I've actually tried to use it for a real-life scenario, none of these tutorials work for very long - I get errors and all kinds of confusion.
  5. Sadly the attitude of lots of git users seems to be very obnoxious and unhelpful. I saw one comment on a blog which said, "we are not going to dumb it down for idiots like you", which is a ridiculous viewpoint since most people are already saying they want to learn it but are struggling. A tool which is elitist is not going to last very long.
  6. The argument, "X thousand people have accounts so it must be good" is flawed. I bet if you compared this to the number of people using Subversion, TFS, mercurial, even MS Sourcesafe I bet it would be tiny in comparison.
  7. The command set is disjointed and confusing in my opinion. Again, I have used various other source control systems and although I have not liked all of these, the basic workflow is very easy to understand and use.
  8. My own opinion is that unless you need to distributed architecture of git, you would be better served using one of the traditional client-server systems. I have reverted to subversion and had it up and running across a dev box, repo server and web server in about an hour. I gave up on Git after the best part of a day.
Sorry git peeps - I'm sure it would only take some command names being changed/aliased and a more helpful introduction to git and people might use it....

Adding sub-sites in IIS7

The title reflects my limited understanding of what I was trying to do in IIS7. I had a web site which was under a domain name which needed to access a web service hosted on the same machine. Since I wanted to use ssl for both and I had a certificate for the top level site, I wanted to host the web service under the other site somehow.
I tried adding it as an application under the main site and pointed to the relevant directory and after the usual fun and games (usually needing to add permissions for \iis_iusrs and iusr to the relevant directories) I was still getting errors and it took a while to spot that the complaint was "assembly X could not be found". What I eventually noticed was that assembly X was referenced by the top level site so why was my web service attempting to load it? It didn't take long to realize that the web service was inheriting the web config of its parent application even though it was in a physically separate directory. I then found good old Rick Strahls blog post here: which identified the workaround as adding a inheritInChildApplications="false"
> tag around system.web and system.webserver elements in the parent site's web config.This indeed stops the inheritance but then I had a follow-on problem with a 500.22 error which detects an invalid config setting for integrated pipeline mode. This is a strange error since all I added was a (valid) location tag but then found another post here: which describes the workaround as removing any httphandlers from the system.web section. I don't know why this only happens with the location tag, perhaps the invalid code is ignored if the config is inherited (since it might be inherited into a classic application pool?) but anyway, in my case, I didn't need the module so I simply removed it and the site came back to life.

Monday, 10 September 2012

Why most passwords policies suck

There are two problems with most passwords policies.
Firstly, some policies are non-existent. This is bad because people use passwords such as "password" or "123456" which are cracked in microseconds, especially if the hacker has access to a long list of passwords and can deduce by statistics what many of the common passwords are.
The second problem, ironically is having a passwords policy that is too strict, you know the sort, "your password must be between 9 and 9.5 characters long including letters, numbers, mixed case, punctuation, arabic and klingon characters". It is bad because it has the smell of security but counter-intuitively is not very secure. Why? Well, most people, I would guess, write down any passwords that are this complex because they can't remember what they typed. Also, just because you require people to use certain characters does not usually enforce how those characters are used. Why is this a problem? Well most of us techies think quite linearly and mathematically. We think an 8 digit password using one of, say, 62 characters gives 2.2e+14 combinations, which if brute forced would therefore take an average of half this number of tries 1.1e+14 which would take a long time (most of us admittedly have no idea how long this would actually take). An article I read recently: says that some cracking systems can process over 6 billion (yes billion) combinations per second meaning a mere five hours is all it takes on average to crack an eight digit password. Actually, it's worse than this because hackers are not standing still and relying on brute force only, they have started to ask how people form passwords and then optimizing their brute force engines accordingly. For instance, I would imagine that most people who are not really educated in these things would say that brute forcing a password would mean starting at aaaaaaaa and then trying aaaaaaab etc until you have got up to ÿÿÿÿÿÿÿÿ but actually this is not necessary. Why? Because although some people might use aaaaaaaa as a password, they are unlikely to use aaacccbb but more likely to use combinations like Mike1963 or @Hello28 Analysis shows that 2 and 4 digit numbers are the norm and most words have a capitalized first letter because it's easier to type. They also suggest that if people use punctuation, it is usually the first or last digit and it is either 1 or 2 characters long - again this makes sense since to most people the punctuation is not part of the word they are thinking of so it has to go before or after.
If you are going to enforce a policy, the best direction to go is definitely password length. Adding another digit to make a 9 digit password increases the number of combinations from 2.2e+14 to 1.4e+16, another 62 times longer in our example. The 5 hours becomes 310 which is already starting to perhaps not be worth it. 10 digits and it becomes 800 days! Personally, if you are going to use passwords then I would recommend that people write long sentences that mean something to them like IWentToTheShopsWithBillyAndHeWantedANewDog which is unlikely to be cracked by brute force and if you try and use a couple of numbers instead of letters etc then I would be much happier with this. The other issue is ALWAYS use variable salt when you hash passwords and NEVER store then in plain text. Even if you encrypt them (which is generally frowned upon), still use variable salt so that if your data is stolen then the hacker has no statistics to work with like which passwords are most common.
You could also look at, a startup who use pictures instead of passwords. This avoids the usual pitfalls of writing passwords down, massively increases the difficulty of phishing and because the ultimate data is not a password in the normal sense, it cannot be dictionary attacked.