"Sir, put your hands behind your back. You're under arrest." I had just participated in my first arrest, and was now on my way to the jail.
Being a rookie, and this being my first time, I was fascinated by the process. As you can imagine, every step my partner took to "book" me was not only very calculated, but also being monitored on video.
Since a jail is filled with suspects of different types of crimes, backgrounds and gangs, all it takes is one second to lose control - and that one second can mean life or death. To prevent this, meticulous planning took place prior to building and staffing the jail. The jail is broken into segments so that if someone manages to escape custody in one area, they are still restricted in their movements in the next area. The staff is carefully trained, and measures are taken to keep weapons and other tools out of the inmates' hands. And everything, and I mean everything, is logged. In essence, a jail is a security maze, as it should be.
In the Web development field, however, the opposite train of thought seems to be the norm. Many developers work under the notion that "no one will try that." The proverbial, we'll fix it if it breaks for someone.
Another all-too-common notion is "it's not that dangerous."
But just like in jails and prisons, all it takes is one second for someone to wreak havoc on your server, or worse, on others by gathering unsecured personal data. Often, a breach ends up costing far more than it would have to fix the problem initially.
It's Your Website/Application
Part of the problem companies face is this idea that it's all about the user. This isn't true. When you planned your website and created the content for it, you were in essence deciding what the user should have access to and how they could access it.
Just like a prison, you can place "doors" on your site and "bars" on certain pages. If the user shouldn't have access to a page, then have the appropriate checks on that page to prevent them from hijacking or guessing a link. In essence, every move the user makes on your website should be controlled by you.
Plan Ahead
Another problem facing many companies is that they don't have a plan for when their site is hacked. It's easy to say that it will never happen, but the reality is large companies - even those that routinely perform code reviews and security audits - get hacked every day. Remember, a jail is designed to be secure, yet prisoners still escape. The same is true with code.
It's imperative to develop a response plan so that when things happen, you have the right people involved to immediately identify, take action, review and fix other possible security breaches.
In prison, when an inmate escapes, guards don't just capture him and move on, instead, they find out where the real problem was. What happened that this security flaw went into production? Are there similar security flaws? Could the fix cause unintended consequences? Ask yourself the same questions.
Train & Restrict Your Staff
Your staff is your most valuable asset. Having a solid, strong team not only prevents many issues from arising, but also allows for your company to respond quickly and proficiently when they do. However, having a poorly trained team, or not taking the time to invest in it, often results in numerous flaws and poor responses to issues.
To avoid this, perform routine trainings and brief staff on any new concerns.
You also need to restrict your staff to prevent accidental security breaches. Using tools such as subversion or Git allow you to code review changes prior to merging them into the master repository, and having multiple layers allows you to adequately test code prior to pushing it out to production.
Likewise, should malicious code get embedded in production, you can always fall back to your internal, untouched repositories.
Just like in prisons, you should know where your staff is at all times, as well as what they are up to. Using a ticket system helps you see what they are working on, and code reviews help to identify any potential issues, allowing for them to be corrected (both in code and in training).
Pat Down Visitors
Prior to being taken to the jail, suspects are searched by law enforcement. They are checked to make sure they don't have any contraband, any illegal substances or items that can be used as a weapon. But once they get to the jail, they're searched again, often more in-depth. There's a reason why.
I'll never forget the night we hauled in a suspect, only to have the jail search him and find a knife. Somehow we missed it, and it could have been a life-changing mistake.
The same is true with Web applications; users should be carefully searched to make sure they're not hiding malicious packets of information. You can tell a lot about a user simply by where they're coming from (IP), where they are trying to go (forms, secured areas, 404ing, etc.) and what they're trying to send you (POST, GET, Cookies).
You can validate things on the front-end, just like law enforcement does, but you should always validate prior to accepting anything on the back-end. After all, you never know when a user is hiding a knife.
And remember, it doesn't matter where they are from, or how nice they seem. In jail a person can go from being calm to out of control in a second. They can go from being the nicest person in the world to threatening your life. Just because they appear to check out OK, don't let your guard down - or you will regret it.
Log Everything
Like in a prison, every action and every movement should be logged. Utilize tracking to see where users are going and what types of responses they are getting. If you notice a URL is getting a lot of 404 errors, beware of this as many times bots try to attack common open-source application URLs. While you may not be running this open source application here, you may have launched it elsewhere or it may even be considered for future use.
Also, repetitive hits on a single page by a single IP may point to an attempted breach, as most users won't view a single, obscure page on your site over and over.
And just as important, logging errors and calls to sensitive data will help you identify where potential problems exist, or if there is code somewhere doing something it's not supposed to do. Overall, you should know what's happening on your website at all times.
Proactively Scan
Similar to a prison guard walking the perimeters, you should also constantly scan your website for errors, mistakes and viruses to ensure no malicious code or programs were uploaded through any backdoors, that there are no broken links or user-facing code-based errors and that all is right within your Web application world.
Call for Backup
This should be part of your response plan - what happens if your team is unable to address the issue? You should have programming SWAT on speed dial.
And what if your code base is compromised? You should have adequate backups (both code and databases) that you can quickly revert to. Keep in mind, backups are only as good as their age, so the sooner you identify a breach, and the more recent your secure backup, the better.
Prison Theory Principles
In a prison no one is allowed to go anywhere except where the jailers want them to go. Every action is controlled and monitored, and in the event an incident occurs, steps are taken immediately to resolve it and prevent any future incidents of similar nature. Application development should operate under these same principles.
About the Author: Mike Stowe (@mikegstowe) is a professional software engineer with more than 10 years of PHP hacking experience. He has built numerous websites and applications, including applications for the medical field, law enforcement, non-profits and more.
