zAy0LfpBZLC8mAC

9 ms·

31.
by zAy0LfpBZLC8mAC 7y ago
> 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 r
32.
by zAy0LfpBZLC8mAC 7y ago
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 interoperabil
33.
by zAy0LfpBZLC8mAC 7y ago
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 consu
34.
by zAy0LfpBZLC8mAC 7y ago
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
35.
by zAy0LfpBZLC8mAC 7y ago
> 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 ac
36.
by zAy0LfpBZLC8mAC 7y ago
> 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 sanitiz
37.
by zAy0LfpBZLC8mAC 7y ago
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?
38.
by zAy0LfpBZLC8mAC 7y ago
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 tha
39.
by zAy0LfpBZLC8mAC 7y ago
Yes. Sanitizing inputs is a bad idea, still.
40.
by zAy0LfpBZLC8mAC 7y ago
There is nothing to protect there, the idea that some data is inherently dangerous is nonsense.
41.
by zAy0LfpBZLC8mAC 7y ago
> 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 &quo
42.
by zAy0LfpBZLC8mAC 7y ago
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.
43.
by zAy0LfpBZLC8mAC 7y ago
> 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
44.
by zAy0LfpBZLC8mAC 7y ago
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
45.
by zAy0LfpBZLC8mAC 7y ago
> 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: Whe
46.
by zAy0LfpBZLC8mAC 7y ago
"Unsafe input" is not a thing.
47.
by zAy0LfpBZLC8mAC 7y ago
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 c
48.
by zAy0LfpBZLC8mAC 7y ago
> 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 "cr
49.
by zAy0LfpBZLC8mAC 7y ago
> 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 somet
50.
by zAy0LfpBZLC8mAC 7y ago
> 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?
51.
by zAy0LfpBZLC8mAC 7y ago
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 do
52.
by zAy0LfpBZLC8mAC 7y ago
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 (thro
53.
by zAy0LfpBZLC8mAC 7y ago
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
54.
by zAy0LfpBZLC8mAC 7y ago
> 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
55.
by zAy0LfpBZLC8mAC 7y ago
Instant (< 10 seconds) is at least possible, if not normal, between any two banks that support SCT Inst (which most do now).
56.
by zAy0LfpBZLC8mAC 7y ago
> 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 Sp
57.
by zAy0LfpBZLC8mAC 7y ago
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
58.
by zAy0LfpBZLC8mAC 7y ago
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 bra
59.
by zAy0LfpBZLC8mAC 7y ago
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
60.
by zAy0LfpBZLC8mAC 7y ago
> 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 n

More ›