https://codeofhonor.substack.com/p/escaping-user-input-is-ridonkulously Code of Honor SubscribeSign in Read in the Substack app Open app Share this post [https] Escaping user input is ridonkulously hard codeofhonor.substack.com Copy link Twitter Facebook Email Escaping user input is ridonkulously hard Sanitization should happen at the framework level, not the application level. But even that's not easy. [https] Noah Oct 16 User supplied HTML should never be considered safe. Always escape user input information, such as information gathered from a form field, before presenting. Go in Practice, Matt Butcher Is there a word for advice that is true, important, and completely useless? There should be. Actually, I just remembered, there is a word! tru*ism: a statement that is obviously true and says nothing new or interesting. Hmm, this seems to imply that the statement means nothing outside of itself. I know, how about this! plat*i*tude: a remark or statement, especially one with a moral content, that has been used too often to be interesting or thoughtful. (example: "he masks his disdain for her with platitudes about how she should believe in herself more") Much better! Let's look at some typical examples of platitudes. * Be yourself * Don't cheat * Escape user input As I'm about to demonstrate, preventing application vulnerabilities by escaping user input is a blackhole of time and energy. Note: escaping user input is necessary and good. I'm just saying that it's hard. (beyond low-hanging fruit a la parameterizing SQL & React escaping HTML) Escaping input does matter, but as advice it's as good as "be faithful to God". An even better term just occurred to me: the GI Joe Fallacy1. That refers to situations where knowing something is far less than half the battle. Highlights from my career Let's start with the very first sanitization bug I ever fixed. It was for a PGP messaging app. An error page displayed an error message. The error message contained the text from the stack trace (as a URL query parameter) that caused the error. The stack trace was rendered directly into the HTML. So if the stack trace contained HTML, that HTML would render. An attacker could exploit this by sending you a message that crashed the app, which would lead to the error page which, in turn, would then load the stack trace. The stack trace would include the text from their message, which would include HTML content that they control! The HTML was sanitized for XSS, but still! They could use it to load, idk, phishing content or something! Here's the full issue for context: HTML Injection issue via msgId. That's pretty tame, so let's look at something more extreme, like the time I won $2,000 for perusing some alarming GitHub issues. CodeCast.io used the Earmark library for parsing Markdown in Elixir. Some candid remarks from the Deprecate sanitize option? issue on Github: Please be aware that Markdown is not a secure format. It produces HTML from Markdown and HTML. It is your job to sanitize and or filter the output of Earmark.as_html if you cannot trust the input and are to serve the produced HTML on the Web. And I guess I'll rather deprecate the option than to fix it, IIUC most markdown converters do not sanitize. Resulting in the video above and me making money. CodeCast is actually still vulnerable to some gnarly rendering issues, even though they fixed the XSS, because safely rendering every possible thing a user might input is just so stupidly difficult to get right. Finally, we can look at a live "vulnerability" on Shodan's API. [https] My lack of responsible disclosure serve as vote of irrelevance on this "vulnerability" . Yet rest assured that most pentesting reports would gleefully include it! Pentesting culture is broken in more ways than just this, I'll write about it separately someday. Security (theater) is a blackhole of time and money Most of the rendering bugs I've seen in security audits don't matter. This is not how your organization will be pwned. Security engineering exists in a cultural bubble nearly devoid of idea germination from the black hat world of cybercriminals. Want to hack a company? 1. Go on LinkedIn and find a sysadmin, DevOps, or SRE person 1. These guys tend to have more access to secrets 2. Bonus points if you stalk them on social media to learn their interests 2. Create a new LinkedIn profile as a pretty girl 3. Message the target asking for mentorship 4. Ask them to run your code 1. The code works and is trivial 2. Something a newbie really might write 3. Oh, but it has an NPM dependency whose subdependency pwns them 1. Cuz NPM dependencies can run arbitrary code during install2 What would fix this? Layered security built around a plausible threat model. What would not help? Removing reflected ASCII text from Shodan's API error message. I'm not saying that small security bugs aren't worth fixing, or that organizational security always trumps application security. Rather, real damage usually does not come from where security engineers tend to expect, because they spend their time on pentests and CTFs that differ substantially from the approaches popular among actual attackers. God forbid these white hats actually bother to crack a real life system. Try it, hack your sister or best friend. What is your first step? Look for SQL injection in her WordPress blog? Unlikely. If you're a cybersecurity professional, I recommend checking out sites like XSS.is and Dread3. Learn how black hats actually operate. Or just hop on Shodan and write a script to autopwn hundreds of machines and build a botnet in an afternoon. If you want a good dork, look no further than port:8888 title:"Home page - Select or create a notebook". [https] To build a get root skiddie-style with this query: Using Shodan Dorks I'm just saying! The conventional wisdom is good, but by itself is not helpful. Especially for the average developer, who cannot reasonably plumb this rabbithole to its depths. For more, admittedly better writing on the topic: * Why "escape on input" is a bad idea * Don't Sanitize, Do Escape * How Much XSS Vulnerability Protection is React Responsible For? By the way, this is first foray into recreational writing! Your criticism is welcome (praise is also okay though!), feel free to leave a comment and I'll respond. If you enjoyed this, please do share. Share Code of Honor I'm a bad writer but your feedback will make me better. 1 https://www.hbs.edu/ris/Publication%20Files/ 21-084_436ebba8-c832-4922-bb6e-49d000a77df3.pdf 2 https://docs.npmjs.com/cli/v8/using-npm/scripts 3 Consult dark.fail for legit URL Comment Share Share this post [https] Escaping user input is ridonkulously hard codeofhonor.substack.com Copy link Twitter Facebook Email --------------------------------------------------------------------- 2 likes Comments [https] [ ] Create your profile [ ] Your name[ ]Your bio[ ] [ ][ ] Subscribe to the newsletter 0 subscriptions will be displayed on your profile (edit) Skip for now Save & Post Comment Only paid subscribers can comment on this post Already a paid subscriber? Sign in Check your email For your security, we need to re-authenticate you. Click the link we sent to , or click here to sign in. TopNewCommunity No posts Ready for more? [ ]Subscribe (c) 2022 The Jesus Privacy [?] Terms [?] Collection notice Publish on Substack Get the app Substack is the home for great writing This site requires JavaScript to run correctly. Please turn on JavaScript or unblock scripts