CATEGORY: Insecure Interaction Between Components
CWE-20: Improper Input Validation
CWE-116: Improper Encoding or Escaping of Output
CWE-89: Failure to Preserve SQL Query Structure (aka ‘SQL Injection’)
CWE-79: Failure to Preserve Web Page Structure (aka ‘Cross-site Scripting’)
CWE-78: Failure to Preserve OS Command Structure (aka ‘OS Command Injection’)
CWE-319: Cleartext Transmission of Sensitive Information
CWE-352: Cross-Site Request Forgery (CSRF)
CWE-362: Race Condition
CWE-209: Error Message Information Leak

CATEGORY: Risky Resource Management
CWE-119: Failure to Constrain Operations within the Bounds of a Memory Buffer
CWE-642: External Control of Critical State Data
CWE-73: External Control of File Name or Path
CWE-426: Untrusted Search Path
CWE-94: Failure to Control Generation of Code (aka ‘Code Injection’)
CWE-494: Download of Code Without Integrity Check
CWE-404: Improper Resource Shutdown or Release
CWE-665: Improper Initialization
CWE-682: Incorrect Calculation

CATEGORY: Porous Defenses
CWE-285: Improper Access Control (Authorization)
CWE-327: Use of a Broken or Risky Cryptographic Algorithm
CWE-259: Hard-Coded Password
CWE-732: Insecure Permission Assignment for Critical Resource
CWE-330: Use of Insufficiently Random Values
CWE-250: Execution with Unnecessary Privileges
CWE-602: Client-Side Enforcement of Server-Side Security

Most of these are also listed on the OWASP Top 10, last updated in 2007 and summarized below. Some come under different names, and I tend to prefer the more generic terms described in the new list of 25.

A1 – Cross Site Scripting (XSS)
A2 – Injection Flaws
A3 – Malicious File Execution
A4 – Insecure Direct Object Reference
A5 – Cross Site Request Forgery (CSRF)
A6 – Information Leakage and Improper Error Handling
A7 – Broken Authentication and Session Management
A8 – Insecure Cryptographic Storage
A9 – Insecure Communications
A10 – Failure to Restrict URL Access

It’s our responsibility as software developers to be aware of these and ensure our architectures and modules do not expose any of these well-defined and documented vulnerabilities.

Option 1: encode=string-ify, decode=eval
The idea here is take a dict and turn it into a string. Then running eval would give you back the original dictionary. If the world were full of with people who danced in flower-filled meadows, this would be ok. The problem is that if you need to pass “s” through an HTTP request, it can be altered into something, like perhaps “os.rmdir(’/’)”

d={'var1':1, 'var2':2}
s="{'var1':1, 'var2':2}"
new_d = eval(s)

Result: VULNERABLE to arbitrary code execution.

Option 2: encode=string-ify, decode=slightly-safter eval
The eval method in python does allow you to tighten it up a bit. There are several articles detailing how to make it slightly safer, by only allowing a certain subset of methods to be available.

new_d = eval(s, {"__builtins__":None}, {})

Result: VULNERABLE to arbitrary code execution.

Option 3: encode=pickle, decode=unpickle
So what if instead of just eval’ing, we used the pickle module to serialize and then deserialize the dictionary? That feels safer at first glance. But what if the object to be deserialized was no longer a dictionary? Perhaps an attacker pickled their own evil object, whose constructor or maybe get() method was modified to do wreak havoc.
Result: VULNERABLE to arbitrary code execution.

Option 4: encode=jsonify, decode=un-jsonify
One technique that didn’t appear in the results was using simplejson to encode and decode. (Thanks Mike Pirnat for suggesting the now-obvious). The simplejson decoder is a much safer one, because it scans the input to make sure it really does look like a dictionary (with all keys and values being safe types) before turning it into a python dict.
User’s can still tamper with the keys and values, but it is no more susceptible than other types of parameter manipulation rampant on the web, so validation still need be there.
Result: much better

Option 5: encode=jsonify(jsonify+hash), decode=un-jsonify plus hash check
To an extra level of comfort, let’s try to make sure that the dictionary wasn’t tampered with. We can take a hash of what we just json-ified, pack it with the data, and json-ify that result. Then when we unpack it, we can double-check that the hash that came with the data still matches a new calculation of the hash of the data. Assuming we have a strong, protected key for our hash algorithm, if the user tried to tamper with the data, they wouldn’t be able to replicate the corresponding change in the hash value, allowing us to raise an exception.
Result: best yet

There ye have it, a safer way of turning a dictionary into a string suitable for passing around the website. Just make sure your hash function is strong and your key is protected.

You can download encode_dict.py to see the final result.

• Port MockMe to the Dojo javascript framework
• Utilize browser history sniffing to build a generalized user segmentation framework
• Write a Ubiquity plugin for spreeder (to easily speed read a page in Firefox)
• Port OWASP’s AntiSamy project to Python, to provide comprehensive XSS protection

None of these are terribly difficult to get started, and with the summer winding down, I might have a few minutes of free time to start working on some.