5 ms·

So then it's fine for an input that deletes your entire database, as long as none of that data makes it back out?

by ehsankia 7y ago

jfkebwjsbx 7y ago
If you are treating inputs as code, you have bigger issues to worry about.
- madsbuch 7y ago
  What is the exact (philosophical?) distinction between data and code? When you extract the host name from email to be able to send a email, you are interpreting a string. We could call this process executing a program that outputs the host name.
  - jeen02 7y ago
    That's the dumbest question I've ever heard
  - jfkebwjsbx 7y ago
    No, that is data, not code. You don't seem to understand the distinction between running algorithms on data and taking programs as input, which is what the GP talked about.
    - dikei 7y ago
      No, he made a good point. It's a matter of perspective, what is considered data in one situation, can be consider code in other situations. Hell, they even created the NX-bit to prevent malicious memory space becoming executable.
      - throwaway373438 7y ago
        Mixing code and data is an inherent attribute of von Newmann architecture computer systems.
    - throwaway373438 7y ago
      I suspect the opposite is true; the parent comment you're replying to is making subtle and insightful commentary on the nature of code and the futility of suggesting that inputs ought not be "code." Any sufficiently complex program can be viewed as an interpreter for its inputs. Input into a calculator program is code which programs an equation. Input into a word processor is code which programs a document. Input into a video game is code which programs a real time simulation. Input into a compiler is code which programs an executable. These are all different types of executable code sequences.
      - jfkebwjsbx 7y ago
        I am a theoretical computer scientist. I can appreciate the insightfulness (on the surface) of that commentary. However, the fact that modern computers can be exploited due to architectural and engineering decisions (eg memory unsafety) does not mean a separation between code and data is not possible. In fact, it is precisely a hot topic how to cheaply bend current practices back to that model given the rampant amount of vulnerabilities in the wild.
        madsbuch 7y ago
        My comment was not limited to the realm of hardware, ISAs and microcode. It was much more general. If you never treat data as code, you can only do uninteresting things. My example was the email address. The instance you look into the "black box" of the string, you are starting to treat the string as an executable structure. An email address' raison d'etre is provide that; an address to send an email to. You can not do that without looking into it. Now, from here we can discuss safe and unsafe ways of doing that. You could use string splits or what not, or you could use a parser combinator library. Doing the latter will make it easy to see that parsing and executing a program is not that different from parsing an email into an AST, (user, hostname), and then treating that as a higher order program (ie. we need to specialize with a message before we can execute it as a "send email" program).
  - kyralis 7y ago
    It depends on context. The question is like asking "what's the difference between 'x + x' and '5'"; the former is 'code', an algorithm with placeholders for data; the latter is data. In another context, though, the function 'f(x) = x + x' might itself be data. Within a given context, however, the answer is generally unambiguous: data is what is acted upon by code. (The breaking of this distinction is one of the reasons self modifying code is Bad.)
  - mikekchar 7y ago
    This reminds me of the trick of repropgramming a computer game by exploiting side effect bugs on controller sequences. There is a youtube video somewhere where somebody writes an entirely new game simply using input sequences on the controller of an existing game. There were bugs that wrote values to various memory locations and by being exceptionally clever you could write assembly code. I wish I could find a link to it...
    - Hasnep 7y ago
      There's lots of examples, but a famous one is this video by Sethbling where he uses a controller as opposed to a TAS tool: https://youtu.be/hB6eY73sLV0 https://youtu.be/hB6eY73sLV0
    - jfkebwjsbx 7y ago
      Yes, it is a consequence of von Neumann archs. No, the fact that current archs encode data and code in the same memory space and there are vulnerabilities does not mean the separation is not possible.
  - roelschroeven 7y ago
    Treating input as data (good): def echo(): user_input = input('enter some text: ') print('your text: {}'.format(user_input)) Treating input as code (VERY BAD, DON'T DO THIS): def echo(): user_input = input('enter some text: ') command = "print('your text: {}')".format(user_input) exec(command) The second example allows the user to do all kinds unintended stuff: enter some text: '); print(10**2000) # your text: 1000000000000000000000... (abridged) That would print however many zeroes the user specified, and use a whole lot of memory. With some creativity it's possible to cause lots of havoc.
onion2k 7y ago
A database query is an output. Anything that your code generates and sends to something else, whether that a web server to answer a user request or an API call to connect with an external service, or an internal request on the server, it's all outputs from your code. No matter how good your input santization is, you still wouldn't ever send an unescaped query to a database, right? That's because the query is an output.
- throwawayjava 7y ago
  ...so the blog post boils down to "sanitize all inputs that don't get piped to /dev/null; also, there are some good libraries that will do that for you (...by escaping outputs... but oh btw those only work sometimes of course, and in other cases, be careful?). In other words, for the love of god please do sanitize your inputs.
  - xenomachina 7y ago
    No. "Sanitize inputs" means modifying the input before you even know where it's going. It's fine for stuff like normalizing user input (eg: "strip leading and trailing spaces") but should not be used to combat things like SQL injection or XSS. For issues like SQL injection and XSS you should escape on output. Outputting HTML? HTML escape, or better yet: use templating framework that does it by default. Outputting to SQL? SQL escape, or better yet use prepared statements and pass in your arguments using an API that escapes by default. In the "sanitize inputs" approach to handling these situations you can't store "O'Hara <3 Sue" as a value, because you need to "sanitize" the apostrophe for SQL and the less-than for HTML. In the "escape outputs" approach, you have "O'"Hara <3 Sue" in your SQL, and "O'Hara <3 Sue" in your HTML, and the user's input is preserved.
    - throwawayjava 7y ago
      > "Sanitize inputs" means modifying the input before you even know where it's going. Okay. That's not how I've ever used that term or seen it used. Prepared statements are a form of input sanitation. HTML purifiers are a form of input sanitation. Maybe this lingo is specific to PHP-land? In any case, "You need to know the semantics of the sink in order to know what to do with an untrusted source" seems like an obvious truism not worth writing about.
thaumaturgy 7y ago
From the article: > Another example of this kind of thing is SQL injection, an attack that’s closely related to cross-site scripting. NaiveSite is powered by MySQL, and it finds users like so: > > $query = "SELECT FROM users WHERE name = '{$name}'"* > > When a boy named Robert'); DROP TABLE users; comes along, NaiveSite’s entire user database is deleted. Oops! Also from the article: > And of course use your SQL engine’s parameterized query features so it properly escapes variables when building SQL: > > $stmt = $db->prepare('SELECT FROM users WHERE name = ?'); > $stmt->bind_param('s', $name); And more from the article: > The parallel for SQL injection might be if you’re building a data charting tool that allows users to enter arbitrary SQL queries. You might want to allow them to enter SELECT queries but not data-modification queries. In these cases you’re best off using a proper SQL parser (like this one) to ensure it’s a well-formed SELECT query – but doing this correctly is not trivial, so be sure to get security review. And the article links to https://stackoverflow.com/questions/129677/how-can-i-sanitize-user-input-with-php/130323#130323 https://stackoverflow.com/questions/129677/how-can-i-sanitiz..., which further explains: > What you should do, to avoid problems, is quite simple: whenever you embed a string within foreign code, you must escape it, according to the rules of that language. For example, if you embed a string in some SQL targeting MySQL, you must escape the string with MySQL's function for this purpose (mysqli_real_escape_string). (Or, in case of databases, using prepared statements are a better approach, when possible.) I hope this satisfactorily answers your question.
deleted 7y ago
[deleted]

So then it's fine for an input that deletes your entire database, as long as none of that data makes it back out?

jfkebwjsbx 7y ago

If you are treating inputs as code, you have bigger issues to worry about.

madsbuch 7y ago
What is the exact (philosophical?) distinction between data and code? When you extract the host name from email to be able to send a email, you are interpreting a string. We could call this process executing a program that outputs the host name.
- jeen02 7y ago
  That's the dumbest question I've ever heard
- jfkebwjsbx 7y ago
  No, that is data, not code. You don't seem to understand the distinction between running algorithms on data and taking programs as input, which is what the GP talked about.
  - dikei 7y ago
    No, he made a good point. It's a matter of perspective, what is considered data in one situation, can be consider code in other situations. Hell, they even created the NX-bit to prevent malicious memory space becoming executable.
    - throwaway373438 7y ago
      Mixing code and data is an inherent attribute of von Newmann architecture computer systems.
  - throwaway373438 7y ago
    I suspect the opposite is true; the parent comment you're replying to is making subtle and insightful commentary on the nature of code and the futility of suggesting that inputs ought not be "code." Any sufficiently complex program can be viewed as an interpreter for its inputs. Input into a calculator program is code which programs an equation. Input into a word processor is code which programs a document. Input into a video game is code which programs a real time simulation. Input into a compiler is code which programs an executable. These are all different types of executable code sequences.
    - jfkebwjsbx 7y ago
      I am a theoretical computer scientist. I can appreciate the insightfulness (on the surface) of that commentary. However, the fact that modern computers can be exploited due to architectural and engineering decisions (eg memory unsafety) does not mean a separation between code and data is not possible. In fact, it is precisely a hot topic how to cheaply bend current practices back to that model given the rampant amount of vulnerabilities in the wild.
      - madsbuch 7y ago
        My comment was not limited to the realm of hardware, ISAs and microcode. It was much more general. If you never treat data as code, you can only do uninteresting things. My example was the email address. The instance you look into the "black box" of the string, you are starting to treat the string as an executable structure. An email address' raison d'etre is provide that; an address to send an email to. You can not do that without looking into it. Now, from here we can discuss safe and unsafe ways of doing that. You could use string splits or what not, or you could use a parser combinator library. Doing the latter will make it easy to see that parsing and executing a program is not that different from parsing an email into an AST, (user, hostname), and then treating that as a higher order program (ie. we need to specialize with a message before we can execute it as a "send email" program).
- kyralis 7y ago
  It depends on context. The question is like asking "what's the difference between 'x + x' and '5'"; the former is 'code', an algorithm with placeholders for data; the latter is data. In another context, though, the function 'f(x) = x + x' might itself be data. Within a given context, however, the answer is generally unambiguous: data is what is acted upon by code. (The breaking of this distinction is one of the reasons self modifying code is Bad.)
- mikekchar 7y ago
  This reminds me of the trick of repropgramming a computer game by exploiting side effect bugs on controller sequences. There is a youtube video somewhere where somebody writes an entirely new game simply using input sequences on the controller of an existing game. There were bugs that wrote values to various memory locations and by being exceptionally clever you could write assembly code. I wish I could find a link to it...
  - Hasnep 7y ago
    There's lots of examples, but a famous one is this video by Sethbling where he uses a controller as opposed to a TAS tool: https://youtu.be/hB6eY73sLV0 https://youtu.be/hB6eY73sLV0
  - jfkebwjsbx 7y ago
    Yes, it is a consequence of von Neumann archs. No, the fact that current archs encode data and code in the same memory space and there are vulnerabilities does not mean the separation is not possible.
- roelschroeven 7y ago
  Treating input as data (good): def echo(): user_input = input('enter some text: ') print('your text: {}'.format(user_input)) Treating input as code (VERY BAD, DON'T DO THIS): def echo(): user_input = input('enter some text: ') command = "print('your text: {}')".format(user_input) exec(command) The second example allows the user to do all kinds unintended stuff: enter some text: '); print(10**2000) # your text: 1000000000000000000000... (abridged) That would print however many zeroes the user specified, and use a whole lot of memory. With some creativity it's possible to cause lots of havoc.

onion2k 7y ago

A database query is an output. Anything that your code generates and sends to something else, whether that a web server to answer a user request or an API call to connect with an external service, or an internal request on the server, it's all outputs from your code. No matter how good your input santization is, you still wouldn't ever send an unescaped query to a database, right? That's because the query is an output.

throwawayjava 7y ago
...so the blog post boils down to "sanitize all inputs that don't get piped to /dev/null; also, there are some good libraries that will do that for you (...by escaping outputs... but oh btw those only work sometimes of course, and in other cases, be careful?). In other words, for the love of god please do sanitize your inputs.
- xenomachina 7y ago
  No. "Sanitize inputs" means modifying the input before you even know where it's going. It's fine for stuff like normalizing user input (eg: "strip leading and trailing spaces") but should not be used to combat things like SQL injection or XSS. For issues like SQL injection and XSS you should escape on output. Outputting HTML? HTML escape, or better yet: use templating framework that does it by default. Outputting to SQL? SQL escape, or better yet use prepared statements and pass in your arguments using an API that escapes by default. In the "sanitize inputs" approach to handling these situations you can't store "O'Hara <3 Sue" as a value, because you need to "sanitize" the apostrophe for SQL and the less-than for HTML. In the "escape outputs" approach, you have "O'"Hara <3 Sue" in your SQL, and "O'Hara <3 Sue" in your HTML, and the user's input is preserved.
  - throwawayjava 7y ago
    > "Sanitize inputs" means modifying the input before you even know where it's going. Okay. That's not how I've ever used that term or seen it used. Prepared statements are a form of input sanitation. HTML purifiers are a form of input sanitation. Maybe this lingo is specific to PHP-land? In any case, "You need to know the semantics of the sink in order to know what to do with an untrusted source" seems like an obvious truism not worth writing about.

thaumaturgy 7y ago

From the article: > Another example of this kind of thing is SQL injection, an attack that’s closely related to cross-site scripting. NaiveSite is powered by MySQL, and it finds users like so: > > $query = "SELECT FROM users WHERE name = '{$name}'"* > > When a boy named Robert'); DROP TABLE users; comes along, NaiveSite’s entire user database is deleted. Oops! Also from the article: > And of course use your SQL engine’s parameterized query features so it properly escapes variables when building SQL: > > $stmt = $db->prepare('SELECT FROM users WHERE name = ?'); > $stmt->bind_param('s', $name); And more from the article: > The parallel for SQL injection might be if you’re building a data charting tool that allows users to enter arbitrary SQL queries. You might want to allow them to enter SELECT queries but not data-modification queries. In these cases you’re best off using a proper SQL parser (like this one) to ensure it’s a well-formed SELECT query – but doing this correctly is not trivial, so be sure to get security review. And the article links to https://stackoverflow.com/questions/129677/how-can-i-sanitize-user-input-with-php/130323#130323 https://stackoverflow.com/questions/129677/how-can-i-sanitiz..., which further explains: > What you should do, to avoid problems, is quite simple: whenever you embed a string within foreign code, you must escape it, according to the rules of that language. For example, if you embed a string in some SQL targeting MySQL, you must escape the string with MySQL's function for this purpose (mysqli_real_escape_string). (Or, in case of databases, using prepared statements are a better approach, when possible.) I hope this satisfactorily answers your question.

deleted 7y ago

[deleted]