3 ms·

> Approximately 100% of CVEs, crashes, bugs, slowdowns, and pain points of computing have to do with various forms of deserialising binary data back into machin

• lioeters 2y ago
  # Top Stubborn Software Weaknesses (2019-2023) Out-of-bounds Write Improper Neutralization of Input During Web Page Generation (‘Cross-site Scripting’) Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’) Use After Free Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') Improper Input Validation Out-of-bounds Read Improper Limitation of a Pathname to a Restricted Directory (‘Path Traversal’) Cross-Site Request Forgery (CSRF) NULL Pointer Dereference Improper Authentication Integer Overflow or Wraparound Deserialization of Untrusted Data Improper Restriction of Operations within Bounds of a Memory Buffer Use of Hard-coded Credentials
  • TeMPOraL 2y ago
    Yup. Almost all of them are various flavor of fucking up a parser or misusing it (in particular, all the injection cases are typically caused by writing stupid code that glues strings together instead of proper parsing).
    • lolinder 2y ago
      That's not parsing, that's the inverse of parsing. It's taking untrusted data and injecting it into a string that will later be parsed into code without treating the data as untrusted and adapting accordingly. It's compiling, of a sort. Parsing is the reverse—taking an untrusted string (or binary string) that is meant to be code and converting it into a data structure. Both are the result of taking untrusted data and assuming it'll look like what you expect, but both are not parsing issues.
      • TeMPOraL 2y ago
        > It's taking untrusted data and injecting it into a string that will later be parsed into code without treating the data as untrusted and adapting accordingly. Which is precisely why parsing should've been used here instead. The correct way to do this is to work at the level after parsing, not before it. "SELECT * FROM foo WHERE bar LIKE ${untrusted input}" is dumb. Parsing the query with a placeholder in it, replacing it as an abstract node in the parsed form with data, and then serializing to string if needed to be sent elsewhere, is the correct way to do it, and is immune to injection attacks.
        • lolinder 2y ago
          For SQL we tend to use prepared statements as the answer, which probably do some parsing under the hood but that's not visible to the programmer. I'd raise a lot of questions if I saw someone breaking out a parser to handle a SQL injection risk.
          • TeMPOraL 2y ago
            That's because prepared statements were developed before understaning of langsec was mature enough. They provide a very simple API, but it's at (or above) the right level - you just get to use special symbols to mark "this node will be provided separately", and provide it separately, while the API makes sure it's correctly integrated into the whole according to the rules of the language. (Probably one other factor is that SQL was designed in a peculiar way, for "readability to non-programmers", which tends to result with languages that don't map well to simple data structures. Still, there are tools that let you construct a tree, and will generate a valid SQL from that.) HTML is a better example, because it's inherently tree-structured, and trees tend to be convenient to work with in code. There it's more obvious when you're crossing from dumb string to parsed representation, and then back.
            • lolinder 2y ago
              The same thing applies to HTML, though: I would shudder if I saw a parser implemented for most HTML injection prevention. The correct answer in almost all cases is to escape the HTML using the language's standard library or the web framework's tooling. The only situation where a parser makes sense over simple escaping routines is if you actually intended to accept a subset of the language that you're injecting into rather than plain text, in which case you'll need more than just a parser to ensure you don't have anything dangerous—you'd need to do a lot of error-prone analysis of the AST afterward as well.
• stouset 2y ago
  > Number one was Out-of-bounds Write (CWE-787) Surely many of these originate from deserialization of untrusted data (e.g., trusting a supplied length). It’s probably documented but I’m passively curious how they disambiguate these cases.
  • throw0101d 2y ago
    >> Number one was Out-of-bounds Write (CWE-787) > Surely many of these originate from deserialization of untrusted data (e.g., trusting a supplied length). Then they would presumably be classified under "Deserialization of Untrusted Data", number fifteen.
    • stouset 2y ago
      That’s entirely my point. If a vulnerability happens due to writing out of bounds during untrusted deserialization, which category would you file it under? “Deserialization of untrusted data” isn’t even a security bug like an out of bounds write is. Every meaningful program deserializes external input. It’s a common area where bugs occur, but it’s not a type of bug in and of itself. Every bug in that category “belongs” in a more proximate category.
• HDThoreaun 2y ago
  Out of bounds write attacks are generally executed on parsers to be fair