‘isSuperUser = true’ and other client-side mistakes

Recently I have tested a couple of commercial web-based applications that send configuration details to the client-side to determine the functionality available to the user. These details were sent as XML to a Java applet or JavaScript via Ajax. So, what’s the problem?

The applications in question had several user roles associated with them, from low privilege users up to administrative users. All these users log into the same interface and features are enabled or disabled according to their role. In addition, access to the underlying data is also provided based on their role. However, in both cases, features were turned on and off in client-side code – either XML or JavaScript. One application actually sent isSuperUser = true for the administrative account and isSuperUser = false for others. A simple change in my client-side proxy actually succeeded in giving me access to administrative features.

The other application had several parameters that could be manipulated, such as AllowEdit. This gave access to some features, but I noticed that there were other functions available in the code that weren’t called by the page. It was a simple matter of looking for the differences between the page delivered to the administrator and that delivered to a low privilege user to find the missing code to call the functions. This was duly injected into the page via a local proxy again and new buttons and menus were added that gave administrative functionality enabled by manipulating the parameters sent, as above. Some might argue that this attack isn’t realistic as I needed an administrative account in the first place, but the code injected would work on every install of the application. You only need that access to one installation of the application, which could be on your own machine, then you can copy and paste into any other instance (or you could simply Google for the code).

It shouldn’t be this easy! Anything set on the client can be manipulated by the user easily. The security of a web application must reside on the server, not on the client. Web application developers must start treating the browser as a compromised client and code the security into the server accordingly.

Base64 Encoding is NOT Cryptography

I have once again come across an IT department who were/are firmly convinced that the commercial web application that they use is secure and has encrypted user details. What it actually does is Base64 encode the password. This is not encryption and must be treated as plaintext.

So what is Base64 encoding and why do we have it? Well, a large number of popular application layer protocols are ASCII text based, i.e. they transfer plain text over the network. A good example of this is HTTP - the protocol used to transfer HTML (or Web) pages around. Originally, only text pages were sent with markup embedded to style it. However, soon other resources were added to the web including pictures, documents, etc. HTTP is designed to transfer plain ASCII text, so how do you transfer a JPEG photograph? Answer: You convert it into plain ASCII text.

The basic principle of converting a file into text is to use the data to represent an index to the ASCII character, e.g. 'A' is 63, 'B' is 64, 'a' is 97, '8' is 56, etc. So, if the first four bytes of your file are 63, 64, 97 and 56, this can be represented by 'ABa8' without loss. However, ASCII is actually only 7 bits and we usually use 8-bit bytes (because of IBM setting the standard - actually a byte was historically just the number of bits required to store a character). Also, ASCII character 13 is a carriage return, 27 is escape and 8 is backspace. These are non-printable and, worse than that, could corrupt the communications as well as remove other characters. So, we can't just do a straight conversion from bytes to ASCII.

This is where Base64 conversion comes in. We split the file up into 6-bit 'bytes', rather than 8-bit. 6 bits give us 64 possible values. These are then represented by the digits, upper and lowercase letters and a couple of symbols ensuring that they are always printable and don't cause problems. So, the Base64 encoded password is just a 6-bit 'byte' representation of an 8-bit byte password and it is trivial to convert between the two. There is no security in Base64 encoding anything. Perhaps I should repeat that again.

Base64 encoding something is not encrypting it and provides NO SECURITY whatsoever!

I am constantly surprised and disappointed that people think that Base64 encoding something will protect it. I know TLS has its problems, but why aren't all web applications using it?

The little JavaScript tool below will allow you to encode and decode Base64 encoded text to see what it's like and how simple it is. If you find Base64 encoded passwords on your network via sniffing then you can use this to decode them.

Enter Text:


Select Encoding or Decoding:

Encode | Decode