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

How we broke PHP, hacked Pornhub and earned $20k

evonide.com

Post reply on HN
Print view View original

91–100 of 107 posts

Re: How we broke PHP, hacked Pornhub and earned $20k

#91

Post by Annatar »

given wrote: post #83

Too bad they didn't just go ahead and: > Dump the complete database of pornhub.com including all sensitive user information. And of course leak the data to expose everyone that participates in this nasty business. It is such a sad thing that people are even proud to work at companies like this where humans are not worth more than a big dick or boobs. And then you get around and say that child porn is so horrible. No,…

Righteous much? The most insidious prison one could ever be put into is the arbitrary restriction in one's own mind. Luckily for the rest of us, we are in the 21st century and most people are educated enough to not believe in nonsense like witches any more. Pornography is heading in the same direction, people are finally starting to realize that sexuality is part of one's natural self. When you consider that each of us was born with a dick or tits, there is nothing wrong by accepting that and getting turned on by appreciating the aesthetics of it. It has been done since antiquity and even before that, and then we regressed into the dark ages of morality. At the very least, it is biology. Science? Yes please!

Re: How we broke PHP, hacked Pornhub and earned $20k

#93

Post by nickpsecurity »

Scaevolus wrote: post #80
haberman wrote: post #78

Earlier quoted context omitted.

> Most hash functions are engineered for speed and collision resistance, in that order. I disagree with that assessment. I think most hash functions are designed for speed and good distribution of outputs given normal inputs. But designing to resist collisions against someone trying to deliberately create them is a different thing entirely. > Trading collision resistance for speed is worthwhile for many workloads, si…

Yes, speed for normal inputs is what's generally desired. A faster hash function can yield better overall performance than having fewer collisions. Here's some empirical evidence for this: https://www.strchr.com/hash_functions The speed is correlated only weakly with the number of collisions-- and using the modern x86 CRC32 instruction yields the best results.

I suggest somebody test SpookyHash-128 similarly to those to see how it performs. Designed to be collision resistant and fast.

http://www.burtleburtle.net/bob/hash/spooky.html

Re: How we broke PHP, hacked Pornhub and earned $20k

#94

Post by geon »

cyphar wrote: post #72
geon wrote: post #20

Earlier quoted context omitted.

Ruby and python aren't exactly known to be fast. In my experience php is fast enough until you start generating lots of garbage. It seems it wasn't really designed to garbage collect at all, but to rely on the per-request cleanup.

> until you start generating lots of garbage We should really stop pretending that the garbage collector is the problem with langauges. The collector isn't the problem, your garbage is the problem. [Not that I'm a proponent of PHP, though it does make popping shells far more fun.]

The code becomes kind of weird when you have to second guess the language.

Now, the approach PHP takes is fine for the original vision of the language. It even works great.

But languages designed for long running processes often have some sort of mechanism for dealing with that situation explicitly. Like the `NSAutoreleasePool` in Objective C. In C++ you might build your own custom slab allocator.

I'd say the garbage collector is one of the problems with PHP. Then again, if you run into it, PHP might not be the right tool for that particular job.

Re: How we broke PHP, hacked Pornhub and earned $20k

#95

Post by fencepost »

seanp2k2 wrote: post #39
fencepost wrote: post #30

So does Pornhub's bug bounty program include some number of years of free paid membership along with financial bounties? Kind of a "treat us right and we'll let you treat yourself right" kind of thing?

If you know enough to be able to pull off hacks like this, you surely know enough to get more of this kind of thing than you'd have time to watch in 10 lifetimes. I doubt that such a "reward" would be very appealing to those who participate in the bug bounty program, and it'd honestly be a sleazy business proposition, which would harm the professionalism of operating a successful bug bounty program. And yes, I'm comp…

I'm glad you were serious, because frankly I wasn't. I'm sure there's more than enough "free" porn out there for just about anyone's taste, so I doubt that free accounts would be a significant incentive anyway.

But meh, sometimes jokes fall flat.

Re: How we broke PHP, hacked Pornhub and earned $20k

#96

Post by JadeNB »

Annatar wrote: post #89
toast0 wrote: post #49

Earlier quoted context omitted.

Never trust user input doesn't mean never use user input; you need to use it carefully -- often that means restricting to acceptable values and lengths, (appropriate!) escaping, and passing through that it's user input to other functions (ex: sql placeholders). When functions do arcane things, and don't let you pass through that it's user provided, that's a red flag. Note that a cookie that you set, and are now getti…

I advised someone doing their masters in information security as a mentor. My student did their dissertation on input scrubbing. We did quite extensive research on the subject, and we found out that a simple AWK program doing regular expression matching on the input, before passing it on to conventional scrubbers inside of languages like PHP virtually eliminated attack vectors. For three months we tried our very best…

> Lesson learned.

Without meaning to be sarcastic (particularly because I found your post interesting), what lesson learned? A casual perusal of your post suggests the lesson "one can't craft SQL code to get by an AWK regex", but, of course, "what I can't do no-one can" is a bad lesson to learn in security.

Re: How we broke PHP, hacked Pornhub and earned $20k

#97

Post by MustardTiger »

dmix wrote: post #90
MustardTiger wrote: post #87

Earlier quoted context omitted.

>I'm curious if Haskell's purity helps developers focus on this issue and therefore makes it easier to mitigate No, haskell's type system does, not its purity. >Given that all user input/state already has to be handled carefully (for ex: with monads) What? Monads are not some mythical beast, there is nothing "handled carefully" about it. A monad is just a general interface.

I'm talking about clear separation of state via Monads making it easier to focus on the riskier input. For example when you are doing code reviews. That is about the developer nothing to do with some inherent functionality of Monads. Not sure what it being a "general interface" has to do with that. Maybe I wasn't clear.

>Not sure what it being a "general interface" has to do with that

I was explaining what monads are. You have read some of the weird misconceptions about haskell and monads and are now repeating them.

Re: How we broke PHP, hacked Pornhub and earned $20k

#98

Post by Annatar »

JadeNB wrote: post #96
Annatar wrote: post #89

Earlier quoted context omitted.

I advised someone doing their masters in information security as a mentor. My student did their dissertation on input scrubbing. We did quite extensive research on the subject, and we found out that a simple AWK program doing regular expression matching on the input, before passing it on to conventional scrubbers inside of languages like PHP virtually eliminated attack vectors. For three months we tried our very best…

> Lesson learned. Without meaning to be sarcastic (particularly because I found your post interesting), what lesson learned? A casual perusal of your post suggests the lesson "one can't craft SQL code to get by an AWK regex", but, of course, "what I can't do no-one can" is a bad lesson to learn in security.

The lesson we learned is that sometimes getting back to the roots (AWK) and using simple methods (regex) can be extremely effective. You are of course right that "what I can't do no-one can" is a bad thing.

Re: How we broke PHP, hacked Pornhub and earned $20k

#99

Post by CiPHPerCoder »

nickpsecurity wrote: post #93
Scaevolus wrote: post #80

Earlier quoted context omitted.

Yes, speed for normal inputs is what's generally desired. A faster hash function can yield better overall performance than having fewer collisions. Here's some empirical evidence for this: https://www.strchr.com/hash_functions The speed is correlated only weakly with the number of collisions-- and using the modern x86 CRC32 instruction yields the best results.

I suggest somebody test SpookyHash-128 similarly to those to see how it performs. Designed to be collision resistant and fast. http://www.burtleburtle.net/bob/hash/spooky.html

Why not SipHash? https://www.131002.net/siphash/

Re: How we broke PHP, hacked Pornhub and earned $20k

#100

Post by hrktb »

Annatar wrote: post #98
JadeNB wrote: post #96

Earlier quoted context omitted.

> Lesson learned. Without meaning to be sarcastic (particularly because I found your post interesting), what lesson learned? A casual perusal of your post suggests the lesson "one can't craft SQL code to get by an AWK regex", but, of course, "what I can't do no-one can" is a bad lesson to learn in security.

The lesson we learned is that sometimes getting back to the roots (AWK) and using simple methods (regex) can be extremely effective. You are of course right that "what I can't do no-one can" is a bad thing.

IMO your lesson is to get to define a problem simply enough that you can apply a simple solution. This is not a given and usually needs serious design and project management skills.

Otherwise even your simple solution would be drawn in "can you support multi-byte characters ? Do you handle non unicode stuff ? What if it leaks in your layers if code before reaching your awk library ?" and other problems that abound in most mildy complex projects.

Post reply on HN