cubicweb #577964 XSS protection [open]
The idea, largely inspired from this article, is to create an unsafe_unicode (and unsafe_str) class that would be the type of untrusted data, coming from the request form and the database ; such string instances would "contaminate" standard python strings when using '+', '%' and other string manipulation operators, that means, the result of all operations with an unsafe instance would be an unsafe insafe too. Only html_escape or alike could turn such a unsafe string into a safe one.
At the end of the request response process, when outputting html mime typed data, we could then check for the string to be safe (and raise an exception for example if needed), preventing security problems like XSS.
This simple idea is very probably easy to implement at first, but many uncontrolled side effects would probably occur, but with the benefit of discovering many security holes in existing code.
|done in||<not specified>|
|closed by||<not specified>|
- cubicweb #246942 supporting aggregates in SET queries
- cubicweb #1698245 Convert __message to _cwmsgid to increase security
- cubicweb #3738011 Candidates related method on Entity
- cubicweb #511718 explain why rql expr insertion doesn't work to ease security debugging
- cubicweb #1381390 Implement HTTP Strict Transport Security for https