Your throat is parched. Your hands are quivering in trepidation. You’ve gone through this situation a million times in your head, but now its actually here and you’ve started to panic. You are about to conduct your first penetration test..
Histrionics aside, most people working in the security industry can probably recall their first pen test. The time they actually got to break away from the intentionally vulnerable hacking playgrounds and attack a live target. Most people start their careers as either developers or network administrators before taking up a position in offensive security. As someone from primarily a development background, I have made a few observations about the way security is perceived on both sides of the fence.
Security is a Post-Thought
Many software developers have a very rough life. The once coveted dream of converting imagination into reality by implementing elegant algorithms to solve complex problems becomes reduced to implementing a list of mundane (usually very ambiguously defined) requirements. If the company is big enough, then most of the fun “heavy lifting” programming exercises have already been handled by an architecture team, and if the company is outsourcing their dev work, then usually architecture isn’t even a consideration. Additionally, project managers are under extreme amounts of pressure to deliver working code to their managers (who are usually non-technical and severely under-scope project hour estimates), and often times place added pressure on their teams to deliver by a given date. Typically, this involves a lot of yelling, screaming, blood, and tears. Often times under these high-pressure circumstances, many factors are overlooked in order to meet deadlines. The first thing to give is typically security.
Most QA teams can figure out if there's a slight functional defect in the application. Some overly ambitious QA teams can find defects in perfectly functional applications (hehe...if you’ve ever worked as a developer, you can probably relate). However, very seldom does a QA team ever pick up on SQL injection or Cross-Site Request Forgery vulnerability. For this reason, its extremely easy for developers to develop a sense of detachment from the product at hand and offer lower quality code. This is a very common problem in the startup scene as well, as many times non-technical founders will have a vision for an application and outsource the development work overseas for cheap. Because many overseas developers (especially contractors) are primarily motivated by financial gain and not so much the vision behind that application, they usually do the minimum amount of work on the app required to get a paycheck.
The difficulty is to then convince a project manager that they should take security more seriously, which leads me to my next observation:
No one really understands security
"Whoa, you're a hacker? Thats so cool, can you hack my friend's {{insert social media application here}}?"
The million-dollar question. Sigh..
Security is (unfortunately) quite esoteric. Even many developers can't wrap their heads around the fact that "client-side security" isn't really a thing, and that the backend service they wrote could result in a full application compromise because they didn't parameterize their queries. I once spent 30 minutes explaining to my developer friend how he should go about fixing the command injection issue I noticed in his application, only to have him ask at the end "wait, command injection is the thing with the pop-ups right?".
The first step in learning about application security involves getting familiar with the characteristics and symptoms of standard attacks.Most of the time, they are so easily preventable that you start questioning whether someone could be so naive as to make such an asinine mistake. Lo and behold, real-life code can be pretty scary at times. Even worse, its extremely difficult to convince a non-technical person that security is a big deal without sounding like a shady hacker trying to browbeat them.
Bullets are Cheaper than Kevlar
Pentesters can be very arrogant at times, it happens to all of us. When you find that stored XSS on an app that has otherwise been relentless, you can't help but feel like a l337 h@x0r from a scene in a Hollywood movie. Most of the times, our job ends when we deliver a PDF file containing all the things another team of devs didn't do right. Naturally, its incredibly frustrating to be on the receiving end of this. The fact of the matter remains, its easy to build things and its even easier to break things, but its incredibly difficult to build things that can't be broken. I think the best pentesters are those people who can completely wipe the floor with an application, but can also properly articulate remediation strategies to developers in a non-patronizing manner.
