{"id":7262,"date":"2013-12-10T10:00:32","date_gmt":"2013-12-10T16:00:32","guid":{"rendered":"http:\/\/www.mrc-productivity.com\/blog\/?p=7262"},"modified":"2022-11-22T13:22:12","modified_gmt":"2022-11-22T19:22:12","slug":"10-security-mistakes-web-application-developers-should-never-make","status":"publish","type":"post","link":"https:\/\/www.mrc-productivity.com\/blog\/2013\/12\/10-security-mistakes-web-application-developers-should-never-make\/","title":{"rendered":"10 security mistakes web application developers should never make"},"content":{"rendered":"

\"Education\"Just when you thought that the healthcare.gov debacle was finally on the uptick, a \u201cwhite hat\u201d hacker just testified on Capitol Hill that security was never properly built into the site<\/span><\/a>. He claims that fixing the critical-to-high exposures could require up to a year of work. <\/p>\n

Not exactly what you want to hear about a website that stores your most sensitive information.<\/p>\n

I bring this up to highlight an important point: Despite the rising importance of proper security, best practices are often ignored. Basic security mistakes still plague many web applications…including healthcare.gov.<\/p>\n

\"photo
photo credit: elhombredenegro<\/a> via photopin<\/a> cc<\/a><\/figcaption><\/figure>\n

As more development shifts to the web, and more data is stored on the cloud, security is a critically important topic. A single security misstep can compromise confidential business data or your customer\u2019s personal information. <\/p>\n

Today, let\u2019s get back to the basics. While web application security is a broad topic, I\u2019d like to focus on the security mistakes that web application developers should never make. These are the \u201cbasic\u201d security principles that should never be ignored. <\/p>\n

So, what are these security principles? What security mistakes should you never make? To help you answer those questions, we\u2019ve compiled advice from some experts in the field (as well as some of my own) and listed everything below. Here are 10 security mistakes you should never make when developing web applications:
\n<\/a><\/p>\n

1. Developing your own security methods<\/h3>\n

Some developers make the flawed assumption that a homegrown algorithm or authentication method is actually safer. After all, hackers have never seen it before, so they\u2019ll have more trouble cracking it…right? Wrong. <\/p>\n

\"photo
photo credit: ePublicist via photopin<\/a> cc<\/a><\/figcaption><\/figure>\n

\u201cDeveloping your own authentication or login methods is a mistake, because you will make a mistake that hackers will discover,\u201d says James Kelley, a Security Engineer at Kelley Consulting Company, LLC<\/span>. \u201cInstead, rely on existing libraries which have been thoroughly tested.\u201d<\/p>\n<\/blockquote>\n

Why are existing libraries more secure? Because they\u2019re constantly tested by the security community. As such, they\u2019re less likely to include major security holes that one person might overlook. As the famous security specialist, Bruce Schneier, likes to say: \u201cAnyone can invent an encryption algorithm they themselves can’t break; it’s much harder to invent one that no one else can break.\u201d<\/p>\n

2. Accessing a database directly with user supplied information<\/h3>\n

\n“When developing an application, particularly a web application, many developers fail to adequately validate the input they receive from users,\u201d says Dwayne Melancon, Chief Technology Officer at Tripwire<\/span><\/a>. \u201cThis has a ‘data hygiene’ impact in that it can allow invalid data to enter your customer database, for example, but it has even greater security implications. Failure to validate input (whether from a web form or via an API) is what allows SQL injection, cross-site scripting, command injection, buffer overruns, and other common web exploits to succeed.\u201d\n<\/p><\/blockquote>\n

This is one of the most common mistakes found in web applications. If unprotected, users can use input fields to inject malicious scripts into your application or access proprietary data from your database. Of course, most users will never attempt anything malicious, but you must approach user input with a defensive mindset.<\/p>\n

\n\u201cDo NOT trust user input, EVER,\u201d says David Campbell<\/span><\/a>, a serial entrepreneur and security expert. \u201cValidate input client side (e.g. Javascript validation), but make sure you also validate it server side. Failing to do this is what creates serious vulnerabilities like cross site scripting and SQL injection.\u201d\n<\/p><\/blockquote>\n

3. Focusing on components, not the overall system<\/h3>\n

With larger development projects–where multiple developers work on different parts of an application–the tendency to focus on individual components arises. Sure, each part may be secure, but…how secure are they as a whole? Remember, your application is only as strong as its weakest point. <\/p>\n

\"photo
photo credit: Horia Varlan<\/a> via photopin<\/a> cc<\/a><\/figcaption><\/figure>\n

“Many security issues happen not within components themselves, but during the ‘handoffs’ that occur as data and processes flow from one part of a business process to the next,\u201d explains Melancon. \u201cDevelopers are often charged with working on one portion of a business process and may not understand other parts of the process. This lack of visibility can allow insecure handoffs to occur, which can expose data to various attacks such as “man in the middle” attacks, data integrity problems, and information leakage.<\/p>\n

It is vital to have a system view of your business service so you can understand how all the components work together and how they can be secured as a combined entity.”<\/p>\n<\/blockquote>\n

4. Adding security at the end of development<\/h3>\n

The problem with the healthcare.gov site: security was never built in. It\u2019s not something you can simply add on at the end. It\u2019s a function of your entire application architecture. As I explained in this article<\/span><\/a>, architecture is the most important aspect of application development because it affects all other aspects of the application…including security. <\/p>\n

\n“While there are any number of symptoms of this mistake, such as misconfigurations and vulnerabilities, they all trace back to treating security like a feature that you can add at the end of development,\u201d explains Tim Erlin, Director of IT Security and Risk Strategy at Tripwire<\/span><\/a>. \u201c’Great, all the functionality works. Now let’s secure it.’ This mentality increases risk by creating architectural security flaws. It’s incredibly hard to deal with things like Cross Site Request Forgery and the many types of SQL injection after the application is fully deployed.”\n<\/p><\/blockquote>\n

5. Letting users create weak passwords<\/h3>\n
\"photo
photo credit: David Chartier via photopin<\/a> cc<\/a><\/figcaption><\/figure>\n

Every time hackers breach a popular web application and expose user passwords, one thing becomes instantly clear: Users have horrible security habits. The most popular password in most every instance: 123456. As a web application developer, you can\u2019t let users create weak passwords.<\/p>\n

\n\u201cA strong password is one that is short enough to remember, but long enough to make it difficult for others to guess,\u201d says Steven Pickles, Co-Founder of Recourier<\/span><\/a>. \u201cRequire a minimum length of at least 10 alphanumeric characters, though passwords that make sense to human brains are more likely to be longer and more effective. Keep in mind it takes eons longer to randomly guess the password \u2018waterdownmobileboomeranggrease\u2019 than it does ‘%sdJil*7m’.\u201d\n<\/p><\/blockquote>\n

He brings up a great point. The best passwords aren\u2019t necessarily the most complex. Forcing users to create overly complex passwords (that they\u2019ll never remember) often leads the user into unsafe practices, like writing their password down and taping it to their computer. The best passwords are both long and memorable.<\/p>\n

6. Storing passwords in plain text<\/h3>\n

\n\u201cThe most common mistake web application developers make is failing to secure user authentication credentials,\u201d explains Pickles. \u201cUsers implicitly trust sites to get this right, but, unfortunately, too many get it wrong. By and large, the culprit is a weakness in the way passwords are handled and stored.\u201d\n<\/p><\/blockquote>\n

The question is, how can you store user passwords correctly? While we could focus an entire article on the proper storage of user authentication credentials, today let\u2019s highlight just one of the most common–yet insecure–practices: storing passwords in plain text.<\/p>\n

\n\u201cNever store passwords in plain text in your database,\u201d says Tirthesh Ganatra, Co-Founder & Lead Developer at PriceBaba<\/span><\/a>. \u201cThis is perhaps the most common mistake we have seen. Many large companies have been shamed in public for this kind of a lapse. Any compromise in your database should not put user data at risk, especially the passwords they use. Thus passwords and other important details of a user should be encrypted and stored in the database.\u201d\n<\/p><\/blockquote>\n

7. Storing data unencrypted in your database<\/h3>\n

A good security rule of thumb: Assume you will get hacked. It\u2019s not a matter of \u201cif\u201d a hacker will gain access to your database. It\u2019s a matter of \u201cwhen\u201d. When a hacker accesses your database, how easily can they steal your data? When left unencrypted, this often leads to massive loss of personal and financial information.<\/span><\/p>\n

\"photo
photo credit: Travis Goodspeed<\/a> via photopin<\/a> cc<\/a><\/figcaption><\/figure>\n

\u201cJust because the database engine requires a username and password doesn’t mean one cannot simply grab the data files and get the information from within,\u201d says Raju Trivedi, Founder of privateborders.com<\/span>. \u201cAnd there is a reliance on the database engine’s security which if flawed would give hackers easy access. This is why so many big gaming and ecommerce sites get hacked and all the personal information including credit card data stolen so often.\u201d<\/p>\n<\/blockquote>\n

8. Passing variables through the URL path name<\/h3>\n

Here\u2019s another dangerous, yet common practice: Many developers place variables in the URL itself, opening the door for hackers to exploit other applications or data. How big of a security risk is this mistake? As you\u2019ll see from the story below, it\u2019s huge.<\/p>\n

\n\u201cNever allow variables that a user interacts with to be part of a path name to a file on your system,\u201d explains Kelley. \u201cWhen auditing a web application, I was once able to exploit a system by making use of a link that allowed downloading a free sample of the product. Coded into the script’s URL was the path to a file to download. I changed the URL to reference a different file, and was able to download the file containing their passwords.\u201d\n<\/p><\/blockquote>\n

9. Only performing authorization on the client side<\/h3>\n

As I touched on in a recent article<\/span><\/a>, we\u2019re seeing more and more development move towards the client side. While this creates faster and more powerful applications, it can create security problems if authorization is handled improperly.<\/p>\n

\n\u201cMore web app developers are relying on the client-side browser to do work that was formerly done server side,\u201d says Jarred White, CISSP, Manager of Security Engineering Services for ControlScan<\/span><\/a>. \u201cThis creates a huge lack of control from a security standpoint, because you don’t know what kind of client is being used. It may not even be a browser at all. Anything that happens on the client side can’t be trusted, so you shouldn’t rely on Javascript or client-side code for critical functions, especially those involving payment information and other sensitive data.\u201d\n<\/p><\/blockquote>\n

10. Assuming it won\u2019t happen to you<\/h3>\n

Two of the most dangerous mistakes you can make when developing web applications: assuming your application won\u2019t be attacked, or assuming you won\u2019t make a mistake. Both of these assumptions lead to lax security practices. Always assume your application will be attacked, and that you will make a security mistake. This mindset will help you avoid future security breaches, and could possibly save your company from embarrassment or financial loss.<\/p>\n

\n\u201cEverybody makes mistakes,\u201d says Campbell. \u201cIf you can find your mistakes before the hackers do, then you’re in good shape! Open source tools like the OWASP ZAP can help you scan your applications for common issues before you push to production.\u201d\n<\/p><\/blockquote>\n

So, what do you think? Obviously, this list could be far longer, but I hope I\u2019ve covered some of the most basic, yet important security mistakes. If you think anything should be added to this list, feel free to share in the comments.<\/p>\n","protected":false},"excerpt":{"rendered":"

Just when you thought that the healthcare.gov debacle was finally on the uptick, a \u201cwhite hat\u201d hacker just testified on Capitol Hill that security was never properly built into the site. He claims that fixing the critical-to-high exposures could require up to a year of work. Not exactly what you want to hear about a …<\/p>\n

10 security mistakes web application developers should never make<\/span> Read More »<\/a><\/p>\n","protected":false},"author":4,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"default","ast-global-header-display":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","slim_seo":{"title":"10 security mistakes web application developers should never make - mrc's Cup of Joe Blog","description":"Just when you thought that the healthcare.gov debacle was finally on the uptick, a \u201cwhite hat\u201d hacker just testified on Capitol Hill that security was never pro"},"footnotes":""},"categories":[8],"tags":[71],"class_list":["post-7262","post","type-post","status-publish","format-standard","hentry","category-education","tag-security"],"_links":{"self":[{"href":"https:\/\/www.mrc-productivity.com\/blog\/wp-json\/wp\/v2\/posts\/7262","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.mrc-productivity.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.mrc-productivity.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.mrc-productivity.com\/blog\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/www.mrc-productivity.com\/blog\/wp-json\/wp\/v2\/comments?post=7262"}],"version-history":[{"count":20,"href":"https:\/\/www.mrc-productivity.com\/blog\/wp-json\/wp\/v2\/posts\/7262\/revisions"}],"predecessor-version":[{"id":14054,"href":"https:\/\/www.mrc-productivity.com\/blog\/wp-json\/wp\/v2\/posts\/7262\/revisions\/14054"}],"wp:attachment":[{"href":"https:\/\/www.mrc-productivity.com\/blog\/wp-json\/wp\/v2\/media?parent=7262"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.mrc-productivity.com\/blog\/wp-json\/wp\/v2\/categories?post=7262"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.mrc-productivity.com\/blog\/wp-json\/wp\/v2\/tags?post=7262"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}