aboutsummaryrefslogtreecommitdiffstats
path: root/askama_escape/src (unfollow)
Commit message (Collapse)AuthorFilesLines
2023-01-30Apply clippy suggestions for 1.67 (#769)Libravatar Dirkjan Ochtman1-2/+1
2022-04-13Remove `unsafe { … }` code from askama_escapeLibravatar René Kijewski1-50/+34
Using only safe code is actually same as fast as the previous "unsafe" code according to the crate's benchmark. The code was extracted from [markup]'s escape function in [escape.rs], written by Utkarsh Kukreti <utkarshkukreti@gmail.com>, licensed as `MIT OR Apache-2.0`. [markup]: https://crates.io/crates/markup [escape.rs]: https://github.com/utkarshkukreti/markup.rs/blob/8ec40428483790b2c296e907e7be4147b157fe8f/markup/src/escape.rs#L1-L21
2022-02-16Make json filter safeLibravatar René Kijewski1-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.
2022-01-06Add `#![deny(unreachable_pub)]` to all cratesLibravatar René Kijewski1-0/+1
2022-01-06Omit implicit lifetimesLibravatar René Kijewski1-2/+2
2022-01-06Add `#[derive(Debug)]` for public typesLibravatar René Kijewski1-0/+3
2021-12-22Fix suggestions from nightly clippyLibravatar Dirkjan Ochtman1-0/+1
2021-07-01Stop eliding lifetimes in pathsLibravatar Dirkjan Ochtman1-0/+1
2021-05-17Remove forward-slash escape (#486)Libravatar Alex Wennerberg1-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
2021-01-15Add no_std support to askama_escapeLibravatar Wim Looman1-3/+10
2020-05-24Update `EscapeWriter` HTML implementation to not output empty stringsLibravatar Ciprian Dorin Craciun1-1/+5
2019-07-25Update formattingLibravatar Dirkjan Ochtman1-4/+1
2019-06-14Change askama_escape to require UTF-8 stringsLibravatar Ram Kaniyur1-24/+25
2019-01-12Specify a trait that handles the output format's escapingLibravatar Dirkjan Ochtman1-55/+108
2019-01-12Slightly simplify escaping codeLibravatar Dirkjan Ochtman1-19/+21
2019-01-06Improved rendering time (#190)Libravatar yossyJ1-1/+23
* Improved rendering time * Fix useless codes
2018-12-08Use 2018 edition idiomsLibravatar Dirkjan Ochtman1-3/+3
2018-11-07Create askama_escape crateLibravatar bott1-0/+100
generated by cgit (git 2.34.1) at 2024-11-23 05:42:28 +0000