The Most Expensive Anti-Pattern(m1el.github.io)

75 pointsby dsegovor 10 Jahren23 comments

m1el.github.io

http://m1el.github.io/printf-antipattern

8 comments

z3t4vor 10 Jahren

When you start to treat HTML as element nodes and child-nodes instead of "strings" things get not only more secure but also much easier to maintain. Use node.appendChild and document.createTextNode! Code example:

  function myButton(parentNode) {
    var button = document.createElement("button");
    button.appendChild(document.createTextNode("Click me"));
    parentNode.appendChild(button);

    button.onclick = function click() {
      button.appendChild(document.createTextNode(" more!"));
    }
  }

AYBABTMEvor 10 Jahren

The funniest example is the one involving `jq` which could have safely manipulated the JSON in one shot, instead of piping this into `sed` & `grep` & `awk`.

jq: bestest tool ever (https://stedolan.github.io/jq/)

MaulingMonkeyvor 10 Jahren

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.

DCodervor 10 Jahren

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

[2] https://wiki.php.net/rfc/taint

apathyvor 10 Jahren

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.

closeparenvor 10 Jahren

>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-engi...

yellowapplevor 10 Jahren

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).

kevinastonevor 10 Jahren

See the 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

apathyvor 10 Jahren

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

xrstfvor 10 Jahren

> 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.

girvovor 10 Jahren

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...

MaulingMonkeyvor 10 Jahren

> 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?

DCodervor 10 Jahren

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.

sqeakyvor 10 Jahren

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.

girvovor 10 Jahren

Right, 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

homakovvor 10 Jahren

I call "printf antipattern" format injection e.g. http://sakurity.com/blog/2015/03/03/duo_format_injection.htm...

telvor 10 Jahren

Stringly-typed programming considered harmful.

scotty79vor 10 Jahren

There should be just html and sql datatypes. They should have own literals and any string converted to html or sql or glued to them should be properly auto-escaped. You could still mess things up if someone malforms literal but it could help with 99% of usual vulnerabilities.

SippinLeanvor 10 Jahren

Better solution for the "Nearly every PHP web-site in existence" example? (I don't know what Hippo is)

SimeVidasvor 10 Jahren

What different serialization format? I thought serialization == string.

Someonevor 10 Jahren

serialization == convert to a byte stream.

The byte stream can be a character stream in whatever encoding or a binary one.

https://en.wikipedia.org/wiki/Comparison_of_data_serializati... lists lots of binary serialization formats.

SimeVidasvor 10 Jahren

I see. Thanks!

DCodervor 10 Jahren

Like it says earlier in the post, it could be enough to only serialize (stringify) the data structure at the very end of building it, once it's finalized. Once it's stringified, it must be treated as a isolated black box, which cannot be inspected, modified, or combined with other black boxes.

I tried to build something like that for rendering HTML, for the same reasons – security and proper structure. But, stupidly, I was working in PHP, and so its syntax was somewhat clunky. I still think it is a good idea, though.

[deleted]vor 10 Jahren