Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Null

popey.com

Post reply on HN
Print view View original

31–40 of 196 posts

Re: Null

#31

Post by lyrrad »

Buildstarted wrote: post #29
xyst wrote: post #11

People like that is the reason why this list was created https://github.com/minimaxir/big-list-of-naughty-strings/blo... My personal favorite is this one though "If you're reading this, you've been in a coma for almost 20 years now. We're trying a new technique. We don't know where this message will end up in your dream, but we hope it works. Please wake up, we miss you.",

Most of the things in this list I can see what they're testing for but your favorite stumps me. Can you give me a hint? Thanks.

I assume it's a joke to test if reality is a simulation or a dream.

Re: Null

#32

Post by masklinn »

Tepix wrote: post #24

Perl 5 has a taint mode built into the language. If enabled, it forces the developer to untaint every bit of user-controllable data (by running it through a pattern match) before doing anything dangerous with it. I can't believe that this isn't a standard feature in all languages.

That’s because it’s both more annoying than warranted and completely insufficient, even ignoring that “running through pattern match” is not great (see: parse, don’t validate).

* “untainting” is highly context-specific, that something was cleaned up for HTML does nothing for SQL

* which also means that the boundary is incorrect, just because you’re getting something out of storage does not mean it’s safe for anything (not even storing it back)

Re: Null

#33

Post by jl6 »

msh wrote: post #28
pixl97 wrote: post #7

>While I’m not a QA or security professional, I have developed a knack for doing “stupid” things with software which causes it to malfunction. A person after my own heart. I've had many a dev go "why would you do that" In which I answer "it doesn't matter, but if you accept my input it's your job to ensure the app doesn't crash"

Why do you require software to be more resilient than other things? If I pour water in the gastank of my car, it will also fail to drive. Or gas in the sprinkler tank. So the car should somehow prevent the enduser putting the wrong thing in the tank?

“Using it wrong” is usually quite obvious with real-life machinery. Software has many more ways of using it wrong that are very unobvious, that the user has no reason to suspect could be dangerous, and that have never been seen before.

Re: Null

#34

Post by iforgotpassword »

msh wrote: post #28
pixl97 wrote: post #7

>While I’m not a QA or security professional, I have developed a knack for doing “stupid” things with software which causes it to malfunction. A person after my own heart. I've had many a dev go "why would you do that" In which I answer "it doesn't matter, but if you accept my input it's your job to ensure the app doesn't crash"

Why do you require software to be more resilient than other things? If I pour water in the gastank of my car, it will also fail to drive. Or gas in the sprinkler tank. So the car should somehow prevent the enduser putting the wrong thing in the tank?

Holding down the button for your hazard lights should not break your car. Holding down a key should not crash an app.

Re: Null

#35

Post by 3pt14159 »

msh wrote: post #28
pixl97 wrote: post #7

>While I’m not a QA or security professional, I have developed a knack for doing “stupid” things with software which causes it to malfunction. A person after my own heart. I've had many a dev go "why would you do that" In which I answer "it doesn't matter, but if you accept my input it's your job to ensure the app doesn't crash"

Why do you require software to be more resilient than other things? If I pour water in the gastank of my car, it will also fail to drive. Or gas in the sprinkler tank. So the car should somehow prevent the enduser putting the wrong thing in the tank?

Because often times crashes in an app lead to information exfiltration or remote code execution.

Re: Null

#36

Post by mikeyjk »

msh wrote: post #28
pixl97 wrote: post #7

>While I’m not a QA or security professional, I have developed a knack for doing “stupid” things with software which causes it to malfunction. A person after my own heart. I've had many a dev go "why would you do that" In which I answer "it doesn't matter, but if you accept my input it's your job to ensure the app doesn't crash"

Why do you require software to be more resilient than other things? If I pour water in the gastank of my car, it will also fail to drive. Or gas in the sprinkler tank. So the car should somehow prevent the enduser putting the wrong thing in the tank?

Security implications, I would imagine.

Re: Null

#37

Post by martijnvds »

msh wrote: post #28
pixl97 wrote: post #7

>While I’m not a QA or security professional, I have developed a knack for doing “stupid” things with software which causes it to malfunction. A person after my own heart. I've had many a dev go "why would you do that" In which I answer "it doesn't matter, but if you accept my input it's your job to ensure the app doesn't crash"

Why do you require software to be more resilient than other things? If I pour water in the gastank of my car, it will also fail to drive. Or gas in the sprinkler tank. So the car should somehow prevent the enduser putting the wrong thing in the tank?

Pumps for different types of fuel have differently shaped nozzles here, making it very hard/impossible to fill up with the wrong kind.

Of course if you're trying to break it, everything is possible.

Re: Null

#38

Post by Buildstarted »

lyrrad wrote: post #31
Buildstarted wrote: post #29

Earlier quoted context omitted.

Most of the things in this list I can see what they're testing for but your favorite stumps me. Can you give me a hint? Thanks.

I assume it's a joke to test if reality is a simulation or a dream.

That makes complete sense and it went right over my head. Thanks

Re: Null

#39

Post by 3pt14159 »

throwaway894345 wrote: post #8
tsujp wrote: post #5

Declarative programming is something that helps deal with weird edge cases like this right? I'm learning Elixir currently and the subtle semantics around the 'traditional' assignment operator (=) are quite cool. It means you can ditch most if blocks and provide a list of pattern-matchable functions (matched on their arity) to define logic which helps deal with edge cases a little better. I'm curious how such a declar…

I don’t see how a string “null” would break anything besides a very stupidly written program (e.g., one which tries to eval() the input) or an ordinary program written in a very stupid language (e.g., one which tries to coerce strings to other types—PHP, is that you?). I’m a big fan of pattern matching (especially statically verified pattern matching so sorry elixir), but I don’t see how it would help here.

Because there was this period of time where the prevailing wisdom was "be liberal in what you accept, and conservative in what you emit" to enable computer systems to handle a wider array of cases. Some people still adhere to it.

I don't. If I want to extend a system that's currently in English to also accept Arabic or Farsi / Persian, you better believe I'm sanitizing that input carefully. Otherwise I'm opening up my application to zero width non-joiners[0] and all sorts of random fingerprinting for my English speaking users. I know it's a pain, but I'd rather just do it right.

[0] https://www.zachaysan.com/zero

Re: Null

#40

Post by masklinn »

msh wrote: post #28
pixl97 wrote: post #7

>While I’m not a QA or security professional, I have developed a knack for doing “stupid” things with software which causes it to malfunction. A person after my own heart. I've had many a dev go "why would you do that" In which I answer "it doesn't matter, but if you accept my input it's your job to ensure the app doesn't crash"

Why do you require software to be more resilient than other things? If I pour water in the gastank of my car, it will also fail to drive. Or gas in the sprinkler tank. So the car should somehow prevent the enduser putting the wrong thing in the tank?

> Why do you require software to be more resilient than other things?

Because software by virtue of not requiring physical access is much easier for bad actors to mess with.

Abuse of such also seems to be classified very differently than abuse of physical systems by human brains e.g. almost no rando would think of putting sugar in your gas tank while walking near your car, but nobody blinks at fucking with your input fields.

Post reply on HN