Hacker News new | past | comments | ask | show | jobs | submit login
How I started in web security (medium.com)
185 points by gkop on Dec 14, 2015 | hide | past | web | favorite | 43 comments

Likewise, my story about how I got into and out of security: it really just takes basic programming knowledge, understanding reverse engineering concept, and constantly testing shit.

When I got kicked out of college for my hack (rm https://news.ycombinator.com/item?id=5090007) all I did was spam URLs with different IDs and test if they returned 200 or 404.. and bam press coverage + job offers. Sometimes the simplest of stuff can lead to nirvana.

I'm no longer in security since it was getting very addicted (I would start testing every website I'd visit for vulbs)..and I had to change and decided to jump into the startup world.

> ... I had to change and decided to jump into the startup world.

You don't have to choose one of them. I was in a similar position about 6 years ago, software + security background and passion for startups which led me to start my own company (https://www.netsparker.com/), we're building a tool to automate web app security and advancing the automated scanning in web apps, it's really fun stuff if you are into security.

Security industry is great for startups and new comers, another option is obviously working for a security startup, there are tons of them.

I've actually heard about your product, as someone was using it against a customer's app portal (on one of our servers). It didn't find an exploit per-se, but it helped us to discover a performance/DoS issue when it would occasionally start crashing + restart a vhost. So, indirectly, thanks for the great product!

Very cool, and indeed combining your strength and helping other ppl at the same time is key for a successful business. Best of luck with Netsparker!

> I would start testing every website I'd visit for vulbs

That's a pretty bad idea if you don't have permission from the owners of the site.

Permission is the enemy of a hacker. Us enthusiasts don't mean any harm and almost never perform tests that break the software (or network). There's a reason why bounty programs exist.

Us enthusiasts might end up in court and/or trouble for that. Do not do pen-testing on systems you don't own or have explicit permission to work on (such permission might be a bug bounty program or something to that effect).

Yes, there is a reason why bounty programs exist, they make it plain that testing is 'ok'. In absence of a bounty program or a relationship with the company you can't claim that you 'don't mean harm' and that your tests would never break the software or the network. It's going to be lumped in with actual attacks.

Not going to lie, every time I'm on a website with some sort of ID in the URL, particularly more obscure ones, I can't help but tamper with it. Try putting quotes in it, try making it a negative value or changing it to nearby values.

I've found a disturbing number of SQL injection and XSS attacks like this, just messing around on obscure sites.

I run a small business and have noticed our customers try to do the same sometimes, their user ID is visible in the URL at some points. I see the error logs saying they tried to load something they didn't have permission for at least a few times a month.

Do you think there's a serious legal risk here, assuming I don't perform any bad queries on the DB but just see an error message from it and assuming I don't give anyone an XSS'd link, just from plain toying with URLs?

One caveat: client side attacks like XSS that don't execute or break backend part are rather ok 100% of time

Simple example that this isn't true: an admin portal that shows requests and doesn't escape properly. Bam, you just broke their whole backoffice.

Simple refxss testing can easily fuck sites up; all the site has to do is stash a query input somewhere that gets rendered back out in JS to all users later (extremely common example: search results).

All the sudden every user on the site is getting alert popups.

A lot of these sites can calculate down to the second and the dollar how much they lose if their site goes down. Guess who's liable if the cause of that downtime is you?

Not even close to true.

At least non-admin XSS is much harder to define as "hacking" by a judge. Otherwise, writing something like "Send your password to ha@ck.er plz!" would be considered severe hacking attempt too.

I don't know what country you're referring to, but in US criminal law, there is no such thing as "hacking". There is only unauthorized use. Cases will turn on whether you should have known that your use of the site while testing for security bugs was unauthorized (short answer: yes, you should have known), and whether it caused damage.

But that's criminal law. That's a real concern, but the bigger concern is tort law. If you blow up someone's site by getting an XSS input cached and replayed to all its users (or, heck, even if you just cause an alarm that they have spend money responding to), you are going to be liable.

That's true. I myself would never poke around some corp. website w/o a bounty program

Then please don't indirectly tell others it is ok to do so. You could cause a lot of trouble for someone who sees you as an authority figure. Of course 'homakov said it was ok' is not a very good defense, but still, better not to encourage dumb/bad behavior.

Is it really? If I just point Burp Suite to some website they're going to come after me?

It depends. If you're testing Facebook, probably not. If you're trying to CSRF wire transfers through your bank, you might get a visit from the authorities.

"""Use your own brain. After all any book is just a list of thoughts of another guy, who might be wrong."""

"""The text above is preface to a little security book I write for newbie hackers and web developers."""

I chuckled.

Just goes to show his honesty :-) "One is not to trust my teachings implicitly but to test them oneself and evaluate their effects." — Buddha (thus making Buddhism perhaps the only "religion" not plagued by faith and dogma, and kind of disseminating the scientific method)

Buddhism is not the only religion not plagued by faith and dogma.

Faith and dogma exist wherever people have outsourced their ability to think. 'Buddhists' do this too, just as some adherents to other faiths do too.

On a side note, the intellectual portions of Vedic literature often emphasise the need for viveka (knowledge, discrimination) and prashnena (questioning) which are requisite qualities of a shisya (student). Arguably, much of Buddhist metaphysics is based on these Upanishadic texts (Vedanta).

Buddha himself was clearly against faith and dogma, and also considered metaphysics irrelevant to the human condition. If you consider Buddhism to be the original teachings, then it's obvious dogma has no place in it, and a person afflicted by dogma could always be pointed to the original teachings. More religious branches of Buddhism exist, but they are blatant bastardizations of the original teachings. This is very different from the situation in other religions, where the original scriptures are the main sources of dogma galore.

Neat article, interesting that suggestions for sane defaults in rails were more-or-less ignored until the problem was demonstrated to easily impact a wide user-base.

That was the source of lolz at the time it happened. If anything, the article demonstrates how little you need to know to break things. In a way, it's a miracle anything works around here.

"If engineers built buildings and bridges the way programmers write software the first woodpecker that would come along would destroy civilization."

That is kind of unfair :)

Typically infrastructure engineers get to (or rather have to) over-engineer things. When you build a bridge you don't build something that is _just_ good enough to hold X cars. You design it to hold X + Y% and/or have Z redundancy

Most software doesn't put peoples lives in danger and thus doesn't get the budget/resources to put in NASA like engineering in software

A lot of engineering is about meeting requirements while keeping costs down. As the joke goes... "Anyone can build a bridge that stands; it takes an engineer to build a bridge that just barely stands"

I realize it's a joke, but even then it's not a good one. The reality is actually the other way around. Anyone can build a bridge that barely stands, but it takes an engineer to build one that still stands after an earthquake.

Uhhhh... see https://en.wikipedia.org/wiki/List_of_Roman_bridges

I'm not sure if the original designers intended for these to have multi-millenia design lives, but I bet that they could have been made much cheaper...

If they were made much cheaper, they likely would not be standing today.

Precisely! Engineering usually isn't about designing the best X, it's about designing the cheapest X that meets all of its requirements.

Edit: even if the requirement is for X to be the best in the world (which, as a non-quantifiable requirement, makes me uneasy), the goal would still be to do it as cost effectively as possible.

That's why our motto is 'move fast and break things' right?

That's sure as fuck not my motto. ;)

Thank you.

Lots of folks chuckled at this when it was first said, but then in the late 90s, the were not chuckling at y2k.

As late as 1986 someone reprimanded me for 'wasting two bytes' in a record.

The more I learn about security, the faster I want to run away from anything related to it.

Being a client-side developer in gamedev (i.e. a space that's not as sensitive to security as a lot of other industries) feels so good.

> Being a client-side developer in gamedev (i.e. a space that's not as sensitive to security as a lot of other industries) feels so good.


A buggy and/or vulnerable game client or server is generally just as hazardous as most any other buggy or vulnerable software.

Buggy game client can only be hazardous if the client/server architecture is built incorrectly — and at least that is not hard to avoid. (Screams "DON'T TRUST THE CLIENT" in the architecture meetings usually help.)

> (Screams "DON'T TRUST THE CLIENT" in the architecture meetings usually help.)

Yeah, except that in many (most?) modern games you can't have a fully-untrusted client... for performance reasons you have to give the client too much information. From what I understand, getting that balance just right is rather tough. :(

> Buggy game client can only be hazardous...

Don't forget that the vast majority of games pass data to 3D graphics card drivers which are terrible, awful, and somewhere between hardly and not at all concerned with security. A bug in a game could hard-lock your system, [0] or lead to code execution in kernelspace. (Not to mention the usual host of problems a buggy program that has read/write access to everything that the system user it's running as, and generally full network access has.)

[0] Despite Windows 7's graphics card driver fault isolation system, I've had a couple of graphics-related hard-lockups in the many years I've been using my gaming PC.

That is how the world works. Proactive security is expensive and it brings no obvious value to the people that manage organization resources.

"A problem is only a problem when it materializes" - that is the way some people think.

I remember when that whole snafu was on the HN front page! :)

(This isn't the exact link I remember seeing, but https://news.ycombinator.com/item?id=3666564 )

I was very intrigued by "Oh, also avoid certifications."

I'm planning to become a solo, freelance, contract worker in IT security.

I have no certs. (I do have a PhD. in a computer related field, though.)

So, how do I convince organizations to hire me in this cert obsessed world?

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact