aboutsummaryrefslogtreecommitdiffstats
path: root/askama_escape/src/lib.rs (unfollow)
Commit message (Collapse)AuthorFilesLines
2023-03-30Use lookup tableLibravatar René Kijewski1-5/+13
2023-03-30Escape HTML fasterLibravatar René Kijewski1-29/+23
Escaped HTML characters vary in length. So, in order to select the correct replacement two variables need to be loaded: The pointer to the new substring and its length. Because of this the generated code is less dense than it could be. With this PR instead of selecting the appropriate `&str`, an `&&str` is selected. The former consumes two words while the latter consumes only one. Intuitively one might assume that the double dereference makes the code slower, but the optimized lookup seems to be so much faster, so that the change is worth its weight. Comparing the result of `cargo bench` (best out of three runs for both): ```text Old: [4.3592 µs 4.3675 µs 4.3764 µs] New: [3.8691 µs 3.8766 µs 3.8860 µs] Diff: [-11.24 % -11.24 % -12.21 % ] ```
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/+0
2018-11-05Reorder and tweak code style a little bitLibravatar Dirkjan Ochtman1-19/+18
2018-11-05Improve performance simplifyLibravatar bott1-32/+20
2018-11-05Escape into FormatterLibravatar Dirkjan Ochtman1-50/+53
2018-11-05Improve performance of html escapeLibravatar bott1-46/+39
2018-10-25Fix off-by-one error with HTML escapingLibravatar Benjamin Li1-1/+2
If the second-to-last character of a string should be escaped, but not the last, the last character was not being included in the result.
2018-06-21Fix formatting with cargo fmtLibravatar Dirkjan Ochtman1-13/+34
2017-11-21Apply suggestions from rustfmt to improve styleLibravatar Dirkjan Ochtman1-8/+4
2017-09-07Rewrite escapable() to prevent duplicationLibravatar Dirkjan Ochtman1-3/+6
2017-09-07Extend escaping according to OWASP recommendationsLibravatar Dirkjan Ochtman1-2/+5
2017-09-04Escape all strings with character entities by default (fixes #23)Libravatar Dirkjan Ochtman1-0/+43
2017-09-04Move escaping algorithm into a separate moduleLibravatar Dirkjan Ochtman1-0/+50