10 Rules for Safer Code

10 RULES
FOR
SAFER
CODEOlivier Dony
@odony

RULE #1
EVAL is EVIL
Don’t trust strings supposed to contain expressions or code
(even your own!)

“eval” breaks the barrier between
code and data
Is this safe?
Maybe… it depends.
Is it a good idea?
No, because eval() is not necessary!

There are safer and smarter ways
to parse data in PYTHON
“42” int(x)
float(x)
Parse it
like this
“[1,2,3,true]”
json.loads(x)
‘{“widget”: “monetary”}’
“[1,2,3,True]” ast.literal_eval(x)
”{‘widget’: ‘monetary’}”
Given this
string

There are safer and smarter ways
to parse data in JAVASCRIPT
“42” parseInt(x)
parseFloat(x)
Given this
string Parse it
like this
“[1,2,3,true]”
JSON.parse(x)
‘{“widget”: “monetary”}’

If you must eval parameters
use a safe eval method
# YES
from odoo.tools import safe_eval
res = safe_eval(’foo’, {’foo’: 42});
# NO
from odoo.tools import safe_eval as eval
res = eval(’foo’, {’foo’: 42});
PYTHON
Alias built-in eval as ”unsafe_eval”
Show your meaning!
# YES
unsafe_eval = eval
res = unsafe_eval(trusted_code);
# NO!
res = eval(trusted_code);
Import as ”safe_eval”, not as ”eval”!

If you must eval parameters
use a safe eval method
JAVASCRIPT
// py.js is included by default
py.eval(’foo’, {’foo’: 42});
// require(”web.pyeval”) for
// domains/contexts/groupby evaluation
pyeval.eval(’domains’, my_domain);
Do not use the built-in JS eval!

50%of vulnerabilities found every year include
remote code execution injected via
unsafe eval

RULE #2
YOU SHALL NOT
PICKLE
Don’t use it. Ever. Use JSON.

“Warning: The pickle module is not intended
to be secure against erroneous or maliciously
constructed data. Never unpickle data
received from an untrusted or
unauthenticated source.

Python’s pickle serialization is:
+unsafe +not portable
+human-unreadable
pickle.dumps({“widget”:“monetary”}) == "(dp0nS'widget'np1nS'monetary'np2ns."
Actually a
stack-based
language!

Pickle is unsafe
Seriously.
>>> yummy = "cosnsystemn(S'cat /etc/shadow | head -n 5'ntR.'ntR."
>>> pickle.loads(yummy)
root:$6$m7ndoM3p$JRVXomVQFn/KH81DEePpX98usSoESUnml3e6Nlf.:14951:0:99999:7:::
daemon:x:14592:0:99999:7:::
(…)
>>>

Use JSON instead!
json.dumps({“widget”:“monetary”}) == '{"widget": "monetary"}'
+safe +portable
+human-readable

RULE #3
USE THE CURSOR
WISELY
Use the ORM API. And when you can’t, use query parameters.

SQL injection is a classical privilege
escalation vector
self.search(domain)The ORM is here to help you build safe
queries:
Psycopg can also help you do that , if you tell
it what is code and what is data:
query = ”””SELECT * FROM res_partner
WHERE id IN %s”””
self._cr.execute(query, (tuple(ids),))
SQL code
SQL data parameters

Learn the API to avoid hurting
yourself
and
other people!

This method is vulnerable
to SQL injection
def compute_balance_by_category(self, categ=’in’):
query = ”””SELECT sum(debit-credit)
FROM account_invoice_line l
JOIN account_invoice i ON (l.invoice_id = i.id)
WHERE i.categ = ’%s_invoice’
GROUP BY i.partner_id ”””
self._cr.execute(query % categ)
return self._cr.fetchall()
What if someone calls it with
categ = ”””in_invoice’; UPDATE res_users
SET password = ’god’ WHERE id=1; SELECT
sum(debit-credit) FROM account_invoice_line
WHERE name = ’”””

This method is still vulnerable
to SQL injection
def _compute_balance_by_category(self, categ=’in’):
WHERE i.categ = ’%s_invoice’
self._cr.execute(query % categ)
Better, but it could still be called
indirectly!
Now
private!

This method is safe against
SQL injection
def _compute_balance_by_category(self, categ=’in’):
categ = ’%s_invoice’ % categ
WHERE i.categ = %s
self._cr.execute(query, (categ,))
Separates code
and parameters!

RULE #4
Fight XSS
So many XSS vectors – gotta watch ’em all

Browsers blur the distinction between
code and data!

Most XSS errors are trivial:
QWeb templates
t-raw vs t-esc / t-field
Only use it to insert HTML code
that has been prepared and
escaped by the framework.
Never use it to insert text.
For everything else, use:
• t-esc: variables, URL parameters, …
• t-field: record data

Most XSS errors are trivial:
DOM manipulations (JQuery)
$elem.html(value) vs $elem.text(value)
Only use it to insert HTML code
that has been prepared and
escaped by the framework.
Never use it to insert text.
For everything else, use:
• t-esc: variables, URL parameters, …
• t-field: record data

@http.route('/web/binary/upload', type='http', auth="user")
    @serialize_exception
    def upload(self, callback, ufile):
        out = """<script language="javascript" type="text/javascript">
                    var win = window.top.window;
                    win.jQuery(win).trigger(%s, %s);
                </script>"""
# (...)
        return out % (json.dumps(callback), json.dumps(args))
Some XSS are less obvious: callbacks
JSON escaping is not sufficient to prevent XSS,
because of the way browsers parse documents!
/web/binary/upload?callback=</script><script>alert(’This works!');//

Users can often upload arbitrary files : contact forms, email
gateway, etc.
Upon download, browsers will happily detect the file type and
execute anything that remotely looks like HTML, even if
you return it with an image mime-type !
Some XSS are less obvious: uploads
<svg xmlns="http://www.w3.org/2000/svg">
<script type="text/javascript">alert(’XSS!!’);</script>
</svg>A valid
SVG image
file!

RULE #5
GUARD PASSWORDS
& tokens fiercely
Secure all user and API tokens, and don’t leak them

Where should we store precious tokens for
external APIs?
On the res.users record of the user!
On the res.company record!
On the record representing the API
endpoint, like the acquirer record!
In the ir.config_parameter
table!
Wherever it makes the most sense, as long as it’s
not readable by anyone!
(field-level group, ACLs, ICP groups, etc.)

Avoid leaking
user cookies
and Session ID

Do not over-Sudo IT
RULE #6
Review 2x your sudo() usage, particularly controllers/public methods

Do you think this form is safe?
Not if it blindly takes the form POST
parameters and calls write() in
sudo mode!

RULE #7
CSRF tokens FOR
website forms
HTTP Posts require CSRF tokens since v9.0

Do you think this form is safe
from CSRF attacks?
As of Odoo 9, HTTP POST controllers
are CSRF-protected
Do not bypass it with GET controllers
that act like POST!

RULE #8
MASTER thE RULES
Odoo ACL and Rules are not trivial, be sure to understand them

Odoo ACLs are not always trivial
user

group B

group A
data
 C
 R
 U
 D
 C
 R
 U
 D
 C
 R
 U
 D
Group
Access Rights
(ir.model.access)
Group
Access Rule
(ir.rule)
Global
Access Rule
(ir.rule)
  123
Per-modelPer-record
ACCESS
DENIED

user

group B

group A
data  C
 R
 U
 D
 C
 R
 U
 D
 C
 R
 U
 D
Group
Access Rule
(ir.rule)
Global
Access Rule
(ir.rule)
  123
Per-modelPer-record
ACCESS
GRANTED
Group
Access Rights
(ir.model.access)

user

group B

group A
data
 C
 R
 U
 D
 C
 R
 U
 D
Group
Access Rule
(ir.rule)
Global
Access Rule
(ir.rule)
  123
Per-modelPer-record
ACCESS
GRANTED
Group
Access Rights
(ir.model.access)

user

group B

group A
data
 C
 R
 U
 D
 C
 R
 U
 D
Group
Access Rule
(ir.rule)
Global
Access Rule
(ir.rule)
  123
Per-modelPer-record
 C
 R
 U
 D
ACCESS
DENIED
Group
Access Rights
(ir.model.access)

user

group B

group A
data
 C
 R
 U
 D
Group
Access Rule
(ir.rule)
Global
Access Rule
(ir.rule)
  123
Per-modelPer-record
ACCESS
GRANTED
Group
Access Rights
(ir.model.access)

RULE #9
There are better and safer alternatives
Getattr is NOT
YOUR FRIEND

Do NOT do this:
def _get_it(self, field=’partner_id’):
return getattr(record, field)
Try this instead:
def _get_it(self, field=’partner_id’):
return record[field]
By passing arbitrary field values, an
attacker could gain access to dangerous
methods!
This will only work with valid field values

RULE #10
Do NOT open(), urlopen(), requests.post(), … an arbitrary URL/Path!
OPEN WITH CARE

Summary
1. Eval is evil
2. You shall not pickle
3. Use the cursor wisely
4.Fight XSS
5. Guard passwords & tokens fiercely
6.Do not over-sudo it
7.CSRF tokens for weBsite forms
8.master THE rules
9.Getattr is not your friend
10.OPEN WITH care

10 Rules for Safer Code

More Related Content

What's hot (20)

Similar to 10 Rules for Safer Code (20)

More from Quang Ngoc (20)

Recently uploaded (20)

10 Rules for Safer Code