5 ms·

Where do you draw the line at "dynamically constructed strings"? Do I need to duplicate the whole query to another literal just to change the sort field? See a

by DCoder 10y ago

Where do you draw the line at "dynamically constructed strings"? Do I need to duplicate the whole query to another literal just to change the sort field? See also: Perl has a "taint mode" [1] which marks all variables receiving external data as "tainted" and disallows their usage in sensitive contexts. PHP has an inactive proposal to implement it as well [2]. [1] http://perldoc.perl.org/perlsec.html#Taint-mode http://perldoc.perl.org/perlsec.html#Taint-mode [2] https://wiki.php.net/rfc/taint https://wiki.php.net/rfc/taint

apathy 10y ago
This is actually a great idea from Perl. Essentially an anti-monad. Somehow it doesn't surprise me that the php proposal is inactive (asterisk). I haven't the foggiest idea what people do today in php but if they don't used cached templates everywhere I will be sad. Even back then we serialized into and "rehydrated" out of memcached and the database (which memcached pulled from on cache misses). It's honestly more of a pain in the ass NOT to use serialized data structures in the long run. It's a good habit that is hard to break once established :-) As far as AST manipulation. Heh. Betcha 9 out of 10 front end programmers have never written a compiler in their life. Again a good habit (somehow this topic always loops around to either lisp or Parsec) but a bit harder to establish. Template metaprogramming is a great way to get in a logit of trouble fast unless you know exactly what you're doing, IMHO. (asterisk) wrote and sold a website in php. I don't judge people by their tools. But a lot of things about php sucked, at least 10 years ago when I stopped needing to write it.
- closeparen 10y ago
  >This is actually a great idea from Perl. Essentially an anti-monad. This is an old and deep idea in computer security. DoD was (is?) interested in systems where, i.e. if a process reads a Top Secret document, then the OS enforces that it can longer write to merely Secret or Unclassified files/IO devices. That way, even a fully compromised process dealing in Top Secret files can't exfiltrate them to a less secure place. It turns out that in systems designed around this "taint" (they call it "label") construct, everything tends to collect the taint/labels, so things having taint can't be restricted very much or the program can't do anything useful. I'm in the middle of this security engineering textbook [0] and I love it. [0] https://www.safaribooksonline.com/library/view/security-engineering-a/9780470068526/ https://www.safaribooksonline.com/library/view/security-engi...
  - kevinastone 10y ago
    See the Bell-LaPadula Model: https://en.wikipedia.org/wiki/Bell–LaPadula_model https://en.wikipedia.org/wiki/Bell–LaPadula_model Implemented in secure systems like Trusted Solaris: https://en.wikipedia.org/wiki/Trusted_Solaris https://en.wikipedia.org/wiki/Trusted_Solaris
  - yellowapple 10y ago
    Tainting is best used for detecting cases where the string in question is both dangerous (e.g. being `eval`ed) and derived from external inputs. I remember being scolded while working my first "real" programming job becaused I used `eval` in a Ruby on Rails codebase (I don't remember the specifics; I think I was trying to hack something together because the controller setup was weird and I was struggling with the "Rails Way™"). Using a quick `eval` to generate the intended code on-the-fly seemed reasonable to me, having previously been intimiately familiar with Perl (where the dangers of `eval` are mostly mitigated thanks to tainting). I subsequently learned to embrace Ruby's more robust metaprogramming facilities, and have since come to appreciate the value (and danger) of macros in languages like Lisp and Elixir, but I still found it interesting that features like tainting aren't more widespread (or if they are, they're not advertised very well).
  - apathy 10y ago
    It's true, SCIF and compartmentalization eventually demands an air gap between TS-SCI and the rest of the world. Eventually everything interesting gets tainted. Hence the suggestion never to run anything with any more ACLs than necessary in production systems that touch non-secured bits
- xrstf 10y ago
  > But a lot of things about php sucked, at least 10 years ago when I stopped needing to write it. Sadly you missed out on the major advances that happened in the PHP ecosystem, like properly namespaced code, massive performance gains since PHP 5.3, Composer, modern frameworks, the PSR initiative (even though one might not agree with all their "standards") and so much more. So I would not judge PHP's evolution by that one proposal ;) A lot more were accepted, implemented and released, from type annotations to the spacechip operator. Personally I'm thankful that nobody further pursued the idea of tainted strings for PHP.
  - girvo 10y ago
    PHP 7 (return type hinting!), PSRs, Composer, and The League of Extraordinary Packages make programming in PHP genuinely nice in 2016. It's kind of amazing, in some ways...
sqeaky 10y ago
Why bother drawing a line, just make more efficient types. In C++11+ Move construction make doing what you want easy and efficient A string type for query could look like its making a copy but just steal the pointers to the buffers the original had, then modify the query part of the underlying buffer. It would cost several more pointer copies than doing it the insecure way a smart compiler would probably optimize those away.
MaulingMonkey 10y ago
> Do I need to duplicate the whole query to another literal just to change the sort field? Works for me! :3 Now, your standard parameterized query API would presumably accept dynamically constructed strings for input parameters (since it's clear from the API that those should be unconditionally escaped, and it can internally do the right thing (tm)) but not the query. On the minus side, being a complete SQL scrub, I'm not sure if this works for specifying sort fields dynamically. Although, I'm already imagining a defcon talk on performing timing attacks against a query that sorts a password field... am I paranoid enough yet?
- DCoder 10y ago
  Typically parameterized query APIs (such as PHP's PDO) only support dynamic parameters for elements that do not affect the query plan, that is, as replacements for literal strings or numbers. Dynamic identifiers, such as table/column names, sort direction, etc., are not allowed. This permits an additional benefit – the DB can compile a prepared statement once and reuse its compiled form for multiple executions.

by DCoder 10y ago

apathy 10y ago

This is actually a great idea from Perl. Essentially an anti-monad. Somehow it doesn't surprise me that the php proposal is inactive (asterisk). I haven't the foggiest idea what people do today in php but if they don't used cached templates everywhere I will be sad. Even back then we serialized into and "rehydrated" out of memcached and the database (which memcached pulled from on cache misses). It's honestly more of a pain in the ass NOT to use serialized data structures in the long run. It's a good habit that is hard to break once established :-) As far as AST manipulation. Heh. Betcha 9 out of 10 front end programmers have never written a compiler in their life. Again a good habit (somehow this topic always loops around to either lisp or Parsec) but a bit harder to establish. Template metaprogramming is a great way to get in a logit of trouble fast unless you know exactly what you're doing, IMHO. (asterisk) wrote and sold a website in php. I don't judge people by their tools. But a lot of things about php sucked, at least 10 years ago when I stopped needing to write it.

closeparen 10y ago
>This is actually a great idea from Perl. Essentially an anti-monad. This is an old and deep idea in computer security. DoD was (is?) interested in systems where, i.e. if a process reads a Top Secret document, then the OS enforces that it can longer write to merely Secret or Unclassified files/IO devices. That way, even a fully compromised process dealing in Top Secret files can't exfiltrate them to a less secure place. It turns out that in systems designed around this "taint" (they call it "label") construct, everything tends to collect the taint/labels, so things having taint can't be restricted very much or the program can't do anything useful. I'm in the middle of this security engineering textbook [0] and I love it. [0] https://www.safaribooksonline.com/library/view/security-engineering-a/9780470068526/ https://www.safaribooksonline.com/library/view/security-engi...
- kevinastone 10y ago
  See the Bell-LaPadula Model: https://en.wikipedia.org/wiki/Bell–LaPadula_model https://en.wikipedia.org/wiki/Bell–LaPadula_model Implemented in secure systems like Trusted Solaris: https://en.wikipedia.org/wiki/Trusted_Solaris https://en.wikipedia.org/wiki/Trusted_Solaris
- yellowapple 10y ago
  Tainting is best used for detecting cases where the string in question is both dangerous (e.g. being `eval`ed) and derived from external inputs. I remember being scolded while working my first "real" programming job becaused I used `eval` in a Ruby on Rails codebase (I don't remember the specifics; I think I was trying to hack something together because the controller setup was weird and I was struggling with the "Rails Way™"). Using a quick `eval` to generate the intended code on-the-fly seemed reasonable to me, having previously been intimiately familiar with Perl (where the dangers of `eval` are mostly mitigated thanks to tainting). I subsequently learned to embrace Ruby's more robust metaprogramming facilities, and have since come to appreciate the value (and danger) of macros in languages like Lisp and Elixir, but I still found it interesting that features like tainting aren't more widespread (or if they are, they're not advertised very well).
- apathy 10y ago
  It's true, SCIF and compartmentalization eventually demands an air gap between TS-SCI and the rest of the world. Eventually everything interesting gets tainted. Hence the suggestion never to run anything with any more ACLs than necessary in production systems that touch non-secured bits
xrstf 10y ago
> But a lot of things about php sucked, at least 10 years ago when I stopped needing to write it. Sadly you missed out on the major advances that happened in the PHP ecosystem, like properly namespaced code, massive performance gains since PHP 5.3, Composer, modern frameworks, the PSR initiative (even though one might not agree with all their "standards") and so much more. So I would not judge PHP's evolution by that one proposal ;) A lot more were accepted, implemented and released, from type annotations to the spacechip operator. Personally I'm thankful that nobody further pursued the idea of tainted strings for PHP.
- girvo 10y ago
  PHP 7 (return type hinting!), PSRs, Composer, and The League of Extraordinary Packages make programming in PHP genuinely nice in 2016. It's kind of amazing, in some ways...

sqeaky 10y ago

Why bother drawing a line, just make more efficient types. In C++11+ Move construction make doing what you want easy and efficient A string type for query could look like its making a copy but just steal the pointers to the buffers the original had, then modify the query part of the underlying buffer. It would cost several more pointer copies than doing it the insecure way a smart compiler would probably optimize those away.

MaulingMonkey 10y ago

> Do I need to duplicate the whole query to another literal just to change the sort field? Works for me! :3 Now, your standard parameterized query API would presumably accept dynamically constructed strings for input parameters (since it's clear from the API that those should be unconditionally escaped, and it can internally do the right thing (tm)) but not the query. On the minus side, being a complete SQL scrub, I'm not sure if this works for specifying sort fields dynamically. Although, I'm already imagining a defcon talk on performing timing attacks against a query that sorts a password field... am I paranoid enough yet?

DCoder 10y ago
Typically parameterized query APIs (such as PHP's PDO) only support dynamic parameters for elements that do not affect the query plan, that is, as replacements for literal strings or numbers. Dynamic identifiers, such as table/column names, sort direction, etc., are not allowed. This permits an additional benefit – the DB can compile a prepared statement once and reuse its compiled form for multiple executions.