Xing \ Creative \ Coding

Web Application Software Development

Firesheep is one app that proved just how easy it is to hijack sessions from sites like Twitter and Facebook when the communication is sent plain-text over HTTP. Thus, if you have any kind of high profile site, SSL has become a MUST. Without SSL, it doesn’t matter what security measures you use or how clever you are because a Man-in-the-Middle (MitM) can simply send your users his own, unsecured, version of your website without all your clever security, your users will happily send the MitM all the information unsecured, and then the MitM can send the data up to your server using your clever security measures…and nobody will ever know the MitM was even there. So, I wish there was another answer, but if you truly want your site to be secure, you must use SSL.

The prevention for an MitM attack is NOT the Asymmetrical RSA encryption like some people probably think. By itself, RSA encryption only prevents passive attackers from reading communications sent between two parties. If encryption is the only security used, then someone who controls the router at your local Starbucks could route all amazon.com traffic to their own computer, and when a user requests amazon.com, they could send the user their own public key, and the user would happily encrypt all their user and credit card information using the attackers public key and send it to the attacker. The attacker would then decrypt it, harvest all the information, encrypt it with amazon’s public key and send it up to amazon.com, and vice-versa. The MitM would be able to sit in the middle harvesting all the information sent between the two parties and be completely invisible…that is…IF encryption were the only security. Fortunately for us, it’s not.

It is not the RSA encryption that makes SSL secure, but rather the Trusted Certificate Authority (CA). When a user connects to a website over SSL, the browser takes the domain name they THINK they are on, the IP address they are actually connected to, and the “public key” (certificate) they were given and verifies all that information against a CA that the browser knows it can trust. If some of the information doesn’t match what the CA has on file, or the website used a CA that your browser doesn’t trust, then the user gets a very ugly security warning from the browser telling the user not to trust the site

Using a signed certificate from a CA, given the same scenario above where the attacker routes all amazon.com traffic to their own computer at IP 10.10.0.10, when the user’s browser reads the certificate and tries to verify it, it will find that the amazon.com certificate they received was “self-signed” or from a CA it doesn’t know or trust, etc., and the subsequent browser warning will hopefully scare the user away. Thus, the only way for an MitM to get away with such a scenario would be to get a Trusted CA to issue them a certificate for amazon.com, which is why CAs make you jump through hoops to get a certificate and charge so much money. CAs actually have a lot of responsibility to their clients and to users whose browsers trust them.

In any case, if you need a secure site, you MUST use SSL. If you don’t use SSL, you will ALWAYS be vulnerable to an MitM attack. By adding more complicated security, you can make it a lot more work for an MitM, and if you have a small user-base, less MitMs will have the opportunity to be in a position to compromise your site. However, ultimately, no matter what you do, your site is vulnerable to MitM attacks without SSL and a signed certificate from a Trusted CA.

February 7th, 2015

Posted In: Security

Tags: , ,

One Comment

Let’s say that your server runs in Central Time but it logs data for facilities all across the US. 99% of the time you won’t have any problem. You’ll grab the Date/Time out of the database, and if displaying to a facility on the East Coast, you convert the Date/Time to Eastern for the user to see. It’s all good. However, you set yourself up for a very big headache in the Fall.

In the Fall, the clocks will move back, which means that your server will experience 1am – 2am twice. If MySQL stored the offset in the DateTime field (e.g. -05:00 before the change and -06:00 after the change), then this wouldn’t be a problem. However, since it doesn’t, when you pull a log out of the table and get the time 1:30am, you have no way of knowing which 1:30am it is, the one before or the one after the change.

If only you had stored the times in UTC you would know which was which.

However, we have a bigger problem. Your Easter timezone facilities’ clocks don’t change back at the same time…they change back at their own 2am. This means that when you translate back and forth between Central and Eastern time, you are going to run into some odd glitches illustrated below. The “Time In” is the valid time sent from the Eastern timezone facility, the “Time Stored” is the time that it gets converted to on the local machine before storage. The “Time Out” is the translation back to local machine time when it pulls it out of the table, and the “Display Time” is the end-result that you display in your logs for the Eastern timezone facility.

Time In Time Stored Time Out Display Time
01:00 EDT 00:00 CDT 00:00 CDT 01:00 EDT
01:30 EDT 00:30 CDT 00:30 CDT 01:30 EDT
01:00 EST 01:00 CDT 01:00 CDT 01:00 EST
01:30 EST 01:30 CDT 01:30 CDT 01:30 EST
02:00 EST 01:00 CST 01:00 CDT 01:00 EST
02:30 EST 01:30 CST 01:30 CDT 01:30 EST
03:00 EST 02:00 CST 02:00 CST 03:00 EST

You’ll notice that you’re all good up until you get to 2:00am EST. Your local machine converts it to local time as 01:00 CST, which is correct. However, since MySQL doesn’t store the offset, when your local machine pulls it out of the database table, it translates it to 1:00am CDT since it doesn’t know which. This results in your Eastern timezone logs having 3 instances of 1am – 2am instead of 2, and a complete loss of the logs from 2am – 3am.

Therefore, if you are working with multiple timezones, or your business might grow to include multiple timezones…start things off the right way. You can avoid this problem by storing your DateTimes in any format that is immune to DST changes. So, the following will all work:

  • Store your Date/Time in UTC. This is the “best-practice” standard.
  • Store the offset as part of the DateTime (e.g. 2014-11-02T02:00:00-05:00). SQL Server has a DateTimeOffset column type, but for MySQL you would have to use a VARCHAR column. Using VARCHAR increases your storage space requirements while also reducing the inherent functionality provided with the DateTime column, so I don’t recommend it.
  • Store in a Unix Timestamp format. This is functionally equivalent to storing in UTC, and is great if you’re storing the time for “right now”, but it is not good for something that needs to store past or future Date/Times because it’s only good for 1970 – 2038. Also, when doing manual queries into the database just to look at the data, timestamps are not human-readable, so I never use them for anything myself.

It can be a bit of a pain getting used to storing data in UTC and then translating it into the display timezone later. However, it avoids many pitfalls, and the work you do up-front to get used to it will pay off in the long run.

December 18th, 2014

Posted In: Software Design

Tags: , , ,

Leave a Comment