Hacker News Reader

zAy0LfpBZLC8mACon Don’t try to sanitize input – escape output

> People seem to prefer web sites that render inconsistently rather than not at all because of one little issue in the markup.

Except those are not the alternatives. The alternatives are consistently rendered websites or inconsistently rendered websites. If browsers had strictly enforced HTML syntax from the beginning, noone would ever have built websites with "little issues in the markup".

IP stacks do not accept randomly misformatted IP packets. The result is obviously not that you constantly encounter internet services that you can not access because your IP stack is picky about broken IP packets, the result is that noone ever sends you broken IP packets.

> It is more robust to render something rather than nothing

No, it just isn't. You are just looking at a very small part of the consequences of this implementation strategy that indeed happens to be positive, but completely ignoring the big picture of all the externalities and other indirect damage that result from it.

> and is one big reason XHTML was abandoned.

Erm ... no? The reason why XHTML was abandoned was because people are incompetent at writing software, and there existed an alternative that allowed them to keep their idiotic practices, including all the vulnerabilities and interoperability problems that result from those, so that's what people did.

> Yes a system that no one uses is more secure than one everybody does.

How does that follow? And what does that have to do with anything?

> Postel's Law is literally in the TCP RFC [1], don't you think that makes it relevant?

Relevant ... for what?

zAy0LfpBZLC8mACon Don’t try to sanitize input – escape output

What is your argument here?

That HTML is a platform with an extraordinary security track record? Noone has ever exploited all the ambiguities that result from the incoherent mess that is the web?

Or is it that we never had any interoperability problems with HTML? All browsers always reliably rendered websites consistently? "This website is optimized for IE" never happened?

How isn't that just the best example to support my point?

As for TCP ... how is it relevant that Postel wrote the spec? Does that mean that the vulnerabilities in TCP never happened? Or are you saying that modern TCP implementations try to accept any crap whatsoever? (No, they don't, of course they don't, people have actually learned that that's a bad idea.)

zAy0LfpBZLC8mACon Don’t try to sanitize input – escape output

No, it's terrible advice as it only causes unnecessary interoperability problems and vulnerabilities. There is no reason why anyone should need to generate invalid input to your program and it is never a better idea to make every consumer more complex to deal with broken input than to make one producer create non-broken output.

The only robustness to invalid input you should have is that you should not fall over when you encounter broken input, but simply reject it.

zAy0LfpBZLC8mACon Don’t try to sanitize input – escape output

I mean, I generally agree, but I think it's already problematic to frame it as "user input that isn't already known to be good". Because "J. O'Brien" is known to be good. The problem is that anyone thinks in the first place that some semantically meaningful input value for some reason is not good.

zAy0LfpBZLC8mACon Don’t try to sanitize input – escape output

> the process of turning data into coherent structures is input sanitization.

No, that is parsing.

> sanitization or validation or conformation - you can argue how to call it and where to use it

Sanitization is "change to make acceptable", validation is "check for conformance and reject what is non-conforming". The first one is practiced by tons of developers and it's a terrible idea, the latter is what you should do. But also, the latter is never about "dangerous" input, it's only about meaningless input.

zAy0LfpBZLC8mACon Don’t try to sanitize input – escape output

> Escaping output does not always work when

Yes, it does. The only exception is if there is no way to represent a given value in the language that you speak to another component, but then you either need to reject the request or sanitize on output (if you can be reasonably sure that doing so won't break the semantics of the information that you are passing on).

> If you don't filter malicious inputs

There is no such thing.

zAy0LfpBZLC8mACon Don’t try to sanitize input – escape output

And what about buffer overflows makes particular data inherently(!) dangerous? As in, what would be an example of data where it is impossible to make it non-dangerous by fixing the buffer overflow that it exploits?

zAy0LfpBZLC8mACon Don’t try to sanitize input – escape output

I think you misunderstood my point. I am not saying that you should reject valid (that is: semantically meaningful) input, but that if you are confronted with semantically meaningless input, you should reject it rather than garble it so that it gains some random meaning.

So:

Name input field, value "J. O'Brien": accept

JSON parameter, value "{foo:bar}": reject

The context was the idea that you should gracefully accept bad input. If your code considers "J. O'Brien" bad input for a name, then that's the problem, not that it doesn't accept bad input.

zAy0LfpBZLC8mACon Don’t try to sanitize input – escape output

Yes. Sanitizing inputs is a bad idea, still.

zAy0LfpBZLC8mACon Don’t try to sanitize input – escape output

There is nothing to protect there, the idea that some data is inherently dangerous is nonsense.

zAy0LfpBZLC8mACon Don’t try to sanitize input – escape output

> The exercise shows that SQL injection (SQLi) now represents nearly two-thirds (65.1%) of all Web application attacks.

Are you sure that you don't actually mean "weird strings sent to web applications" when you write "web application attacks"? Sending a weird string to web applications is not an attack in any particularly relevant sense unless there is an actual vulnerability--other than when akamai wants to sell you snake-oil against all the danger of weird strings.

zAy0LfpBZLC8mACon Don’t try to sanitize input – escape output

No, the browser will decode & in the HTML into the '&' character and will submit that character back to you if it is part of some form field.

zAy0LfpBZLC8mACon Don’t try to sanitize input – escape output

> The point of hand sanitizer is to reject infectious diseases outright.... you know, so they don’t get IN your body.

There is no such thing as "infectious input data".

> You seem to have adopted a narrowly defined sense of sanitization which does not include “mercilessly discard/destroy”.

None of the dictionaries I just checked support such a definition. They are all about "changing something to be more sane/sanitary/pleasant/acceptable/...".

Also, mind you a hand sanitizer doesn't destroy your hand, it destroys microbes, in order to make your hand sanitary, so as to enable you to continue using your hand instead of rejecting/disarding it. Which is exactly the kind of thing you should not ever do with input data.

zAy0LfpBZLC8mACon Don’t try to sanitize input – escape output

No, it doesn't. That is what "accept anything" programming leads to.

The idea that "accepting all the inputs" somehow gives you an advantage is an illusion: If the semantics of some input are not well-defined, then the only thing you gain by accepting it anyway are hard to debug interoperability problems and vulnerabilities. When some input is not well-defined accoridng to the spec, then your interpretation is just a random guess, and the next developer will make a different random guess as to what that input means, and so an interoperability problem and potential vulnerability is born. If you reject the invalid input, you will notice the error and thus fix the source of the invalid input to produce input for which the semantics are actually well-defined.

zAy0LfpBZLC8mACon Don’t try to sanitize input – escape output

> Output filtering has the complimentary problem -- you need to understand every possible input.

No, you simply need to understand the encoding rules of the sink. Which is precisely why "sanitizing input" is plain nonsense: Whether a particular unescaped character has some meta character function is not a property of the character, but of the output language, so you can not possibly "sanitize input" in any meaningful sense, unless you mean by that "randomly garble the input".

zAy0LfpBZLC8mACon Don’t try to sanitize input – escape output

"Unsafe input" is not a thing.

zAy0LfpBZLC8mACon Don’t try to sanitize input – escape output

Now, you have ammended your comment to really say something very different (how is parameterized SQL 'basic' anything when it's actually the correct complete solution to the problem?).

But in any case, this still suggests a complete misunderstanding of the point of that blog post. As far as that blog post's point is concerned, the SQL database is an output of your program. And the whole point is that you need to escape/encode all outputs correctly, but you should not ever sanitize anything.

zAy0LfpBZLC8mACon Don’t try to sanitize input – escape output

> Code should ideally be correct and fail-safe; deal gracefully with bad input, ensure correct output, at all levels. Ideally.

NO!

If you get bad input, you should fail, loudly. Anything else is a recipe for disaster.

(Not as in "crash the whole system", of course, but as in "reject the request".)

zAy0LfpBZLC8mACon Mozilla’s DNS over HTTPs

> Generally arguments are based on facts. [...]

How is that relevant to your assertion that it is up to you to decide when something needs to be discussed and apparently trying to use that as an argument?

> I'm not refuting something you didn't bring up.

Could you please point to where I said we should conclude that they are currently breaking their agreement, then?

zAy0LfpBZLC8mACon Mozilla’s DNS over HTTPs

> If they do, then we can all have that conversation.

That is not how arguments work.

> But just because they could break the agreement does not mean we should jump to any conclusion that they are currently.

Oh, and straw-maning, too? Brilliant!

zAy0LfpBZLC8mACon Mozilla’s DNS over HTTPs

No, it clearly says that if they haven't figured out a business model yet, the business model they will end up figuring out might just as well be selling your data, so it's maybe not wise to make the internet depend on them not doing so.

zAy0LfpBZLC8mACon Teardown of a $1.25 LED Lightbulb

The purpose of separate wires is twofold:

1. It's to provide protection in case of neutral failure. If you have an appliance with the case grounded via neutral and the neutral wiring fails, you now have the case connected to live (through any appliance that is switched on). With separate ground, nothing happens as you are only allowed to connect ground to neutral at a point where failure of the upstream wiring is practically impossible (i.e., wires so thick that they practically won't break).

2. It's to provide a path for ground fault currents that does not pass through the RCD, if you have an RCD. While neutral doesn't go through the circuit breaker, it does go through the RCD, so as to measure the difference in current between live and neutral. If your appliance is grounded vial neutral, any ground fault (connection from live to the case) looks like regular load current to the RCD, if it is grounded via separate ground, the fault current bypasses the RCD and thus causes it to trigger, even for a small current that would not trigger over current protection.

zAy0LfpBZLC8mACon Let's Encrypt: an automated certificate authority to encrypt the entire web

No, you only need an additional name server to serve one name, and it doesn't even have to be particularly reliable or fast or anything for most uses, as long as it's available at some point for a cert renewal before the old cert expires.

So, you can just put that nameserver on any machine that has a static IP address, or even a semi-static address, like, your home router or something.

zAy0LfpBZLC8mACon N26 will be leaving the UK

> Almost all commercial banks offer SCT.

Of course they do. That's the normal, slow money transfer, aka "SEPA Credit Transfer". I suppose you mean SCT Inst?

Even of the bigger retail banks, Consors and ING do not offer SCT Inst.

> And most of them for free while most co-op/sparkassen charge a fee (some of them even for receiving an instant payment which is rediculous).

While it is included at Deutsche Bank proper, both Norisbank and Postbank charge between 0.50 and 1.00 EUR for outgoing SCT Inst, Commerzbank proper charges 1.50 EUR unless you are in one of their premium plans while comdirect (though technically not yet fully part of Commerzbank) is free, Hypovereinsbank is free for all non-business accounts except the cheapest ones, where it's 0.50 EUR.

So ... erm, no, not even close to "most of them for free"?

Also, on the other hand, there are co-op banks that offer free accounts with free SCT Inst nationally.

But who is charging for receiving SCT Inst payments? I hadn't heard of that before, that's indeed beyond ridiculous!

> Sparkassen failed at numerous attempts to come up with an online payment system that gets any traction and it took considerably longer for them to adopt apple pay.

And yet, they (all) implement SCT Inst!?

zAy0LfpBZLC8mACon N26 will be leaving the UK

Instant (< 10 seconds) is at least possible, if not normal, between any two banks that support SCT Inst (which most do now).

zAy0LfpBZLC8mACon N26 will be leaving the UK

> Germany has huge numbers of banks compared to other countries and so the system is inefficient.

That's not really true. While there is a huge number of banks, most of them are either co-op banks (Raiffeisen- and Volksbanken) or Sparkassen, and while they are all separate legal entities, all the banks from either of those groups run on their respective common infrastructure (Ficudia & GAD IT and Finanz Informatik).

zAy0LfpBZLC8mACon N26 will be leaving the UK

https://de.wikipedia.org/wiki/N26_(Direktbank)#Kritik

And in particular:

https://www.heise.de/newsticker/meldung/33C3-Schwere-Sicherh...

Banks in general are terrible at IT security here, but N26 seems to be the particularly special completely and utterly incompetent kind of terrible.

zAy0LfpBZLC8mACon N26 will be leaving the UK

It's not even a thing "in Germany". There may be some banks that do this, but I would say most don't. But then, most banks are relatively regional, so while you can use any branch of the bank, there won't be any branches of your bank if you travel far enough--and if you are with your local Sparkasse, for example, then that is your bank, the Sparkasse in the next bigger city over has nothing to do with them (well, yeah, they have, but they most definitely are a separate bank).

zAy0LfpBZLC8mACon N26 will be leaving the UK

It's just that all co-op banks and Sparkassen have implemented SCT Inst (instant payment), while quite a few "commercial" banks have not (though the big two have). Though some of them do charge fees, some even outrageous fees, for the privilege of non-stone-age transfers (but then, others don't).

zAy0LfpBZLC8mACon Apple’s independent repair program is invasive to shops and their customers

> Loaded because it was clearly setting the scene for you to engage in reductio ad absurdum, which you promptly did.

That's ... not what a loaded question is? A loaded question is a question that presupposes as fact that for which no agreement exists, which is why it is fallacious. Setting up a scenario to support one's own position is exactly the opposite of that: It's the honest thing to do.

Also, what exactly is wrong with a reductio ad absurdum? It's certainly not a fallacy!?

> The contractual clause in your example would be unenforceable so your point is moot.

When someone asks you "do you think that X should/should not be legal", answering "X is/is not legal" is a fallacy known as dodging the question. Ironic given how much you seem to dislike fallacies that aren't even fallacies!?

> If you want to debate the matter maturely then I’m all ears, but if you just want to shoe horn my words to make ridiculous non-points then I see little point continuing.

"maturely" as in I may only make arguments that agree with your position (because you seem to object to logically valid arguments simply because they contradict your position), while you are free to use fallacies as it suits you (which is what you have done)? I think that's the kind of approach that I would generally use the label "immature" for, but I guess labelling that as "mature" fits right in with you being the one to use all the fallacious arguments?!