The Sin Explained

There are two distinct errors associated with this sin, so lets take a look at them one at a time.

Magic URLs

The first error is Magic URLs, or URLs that contain sensitive information or information that could lead an attacker to sensitive information. Look at the following URL:

www.xyzzy.com?id=TXkkZWNyZStwQSQkdzByRA==

We wonder what that is after the id. Its probably base64 encoded; you can tell that by the small subset of ASCII characters and the = padding characters . Quickly passing the string through a base64 decoder yields My$ecre+pA$$w0rD. You can see immediately that this is actually an encrapted password, where the encryption algorithm is base64! Dont do this if you care about the sensitivity of the data.

The following short C# code snippet shows how to base64 encode and decode a string:

 string s = "<some string>"; string s1 = Convert.ToBase64String(UTF8Encoding.UTF8.GetBytes(s)); string s2 = UTF8Encoding.UTF8.GetString(Convert.FromBase64String(s1)); 

In short, data held anywhere in the URL, or the HTTP body for that matter, that is potentially sensitive is sinful if the payload is not protected by some appropriate cryptographic means.

Something to consider is the nature of the web site. If the URL data is used for authentication purposes, then you probably have a security issue. However, if the web site uses the data for membership, then perhaps its not a big deal. Again, it depends what youre trying to protect.

Imagine the following scenario: You build and sell an online photographic web site that allows users to upload their holiday snaps . This could be deemed a membership system because the photos are probably not sensitive or classified . However, imagine if an attacker (Mallet) could see another user s (Daves) credentials (username, password, or magic value) fly across the wire in the URL or HTTP payload. Mallet could create a payload that includes Daves credential to upload porn to the web site. To all users of the system, these pictures appear to come from Dave, not Mallet.

Hidden Form Fields

The second error is passing potentially important data from your web application to the client in a hidden form field, hoping the client doesnt (1) see it or (2) manipulate it. Malicious users could very easily view the form contents, hidden or not, using the View Source option in their browsers, and then create malicious versions to send to the server. The server has no way of knowing if the client is a web browser or a malicious Perl script! See the example sins that follow to get a better idea of the security effect of this sin.

Related Sins

Sometimes web developers perform other sins, such as the sin outlined in the preceding section Magic URLs: the sin of using lousy encryption.