4 ms·
I see these all as type errors enabled by having a single unified string type for all things. Something as simple as forcing mysql_query to accept only literal
by MaulingMonkey 10y ago
I see these all as type errors enabled by having a single unified string type for all things.
Something as simple as forcing mysql_query to accept only literal strings, forbidding dynamically constructed strings, would change it from an API so unsafe by design that PHP deprecated it - and then removed it - into something relatively safe.
- DCoder 10y agoWhere 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 agoThis 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 agoSee 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 agoTainting 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).
- 10y ago
- sqeaky 10y agoWhy 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 agoTypically 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.
- girvo 10y agoRight, exactly. In Nim, I often leverage TaintedString; this means that things that _do_ expect Strings can't accept it without it being run through some other validation/sanitisation proc to convert it to a "real" String type