aboutsummaryrefslogtreecommitdiffstats
path: root/askama_escape/src (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Make json filter safeLibravatar René Kijewski2022-02-161-4/+52
| | | | | | | | | | | | | | | | | | | | | Previously the built-in json filter had an issue that made it unsafe to use in HTML data. When used in HTML attributes an attacker who is able to supply an arbitrary string that should be JSON encoded could close the containing HTML element e.g. with `"</div>"`, and write arbitrary HTML code afterwards as long as they use apostrophes instead of quotation marks. The programmer could make this use case safe by explicitly escaping the JSON result: `{{data|json|escape}}`. In a `<script>` context the json filter was not usable at all, because in scripts HTML escaped entities are not parsed outside of XHTML documents. Without using the safe filter an attacker could close the current script using `"</script>"`. This PR fixes the problem by always escaping less-than, greater-than, ampersand, and apostrophe characters using their JSON unicode escape sequence `\u00xx`. Unless the programmer explicitly uses the safe filter, quotation marks are HTML encoded as `&quot`. In scripts the programmer should use the safe filter, otherwise not.
* Add `#![deny(unreachable_pub)]` to all cratesLibravatar René Kijewski2022-01-061-0/+1
|
* Omit implicit lifetimesLibravatar René Kijewski2022-01-061-2/+2
|
* Add `#[derive(Debug)]` for public typesLibravatar René Kijewski2022-01-061-0/+3
|
* Fix suggestions from nightly clippyLibravatar Dirkjan Ochtman2021-12-221-0/+1
|
* Stop eliding lifetimes in pathsLibravatar Dirkjan Ochtman2021-07-011-0/+1
|
* Remove forward-slash escape (#486)Libravatar Alex Wennerberg2021-05-171-1/+0
| | | | | | | | | | | | | | | This was based off of the OWASP XSS prevention cheat sheet -- https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html#output-encoding-rules-summary However, there isn't really any attack vector based on forward slash alone, and it's being removed in the next version of that document. > There is no proof that escaping forward slash will improve > defense against XSS, if all other special characters are escaped > properly, but it forces developers to use non-standard implementation of > the HTML escaping, what increases the risk of the mistake and makes the > implementation harder. https://github.com/OWASP/CheatSheetSeries/pull/516
* Add no_std support to askama_escapeLibravatar Wim Looman2021-01-151-3/+10
|
* Update `EscapeWriter` HTML implementation to not output empty stringsLibravatar Ciprian Dorin Craciun2020-05-241-1/+5
|
* Update formattingLibravatar Dirkjan Ochtman2019-07-251-4/+1
|
* Change askama_escape to require UTF-8 stringsLibravatar Ram Kaniyur2019-06-141-24/+25
|
* Specify a trait that handles the output format's escapingLibravatar Dirkjan Ochtman2019-01-121-55/+108
|
* Slightly simplify escaping codeLibravatar Dirkjan Ochtman2019-01-121-19/+21
|
* Improved rendering time (#190)Libravatar yossyJ2019-01-061-1/+23
| | | | | | * Improved rendering time * Fix useless codes
* Use 2018 edition idiomsLibravatar Dirkjan Ochtman2018-12-081-3/+3
|
* Create askama_escape crateLibravatar bott2018-11-071-0/+100
generated by cgit (git 2.34.1) at 2024-11-22 10:10:11 +0000