Risk
9/7/2012
01:52 PM
Connect Directly
RSS
E-Mail
50%
50%

6 Ways To Strengthen Web App Security

Want to keep your Web application from getting hacked? Here's how to get serious about secure apps.

11 Security Sights Seen Only At Black Hat
11 Security Sights Seen Only At Black Hat
(click image for larger view and for slideshow)
Let's get serious about building secure Web applications.

The reasoning is simple: According to numerous studies, the preferred method for attacking businesses' online assets is via their Web applications--and why not? According to a study released last year by HP, 69% of Web applications scanned by the company had at least one SQL injection error, and 42% contained a cross-site scripting vulnerability.

So, for every known Web application, seven times out of 10 there is at least one--and usually, more than just one--SQL injection flaw just waiting to be discovered by an enterprising hacker. As cryptographer Whitfield Diffie noted earlier this year at the Black Hat Europe conference, information security defenders get dinged when they don't do their job perfectly. But attackers get to play by "good enough" rules: succeeding even one time out of 100 or 1,000 can equal victory. Furthermore, hackers even have automated attack tools to eliminate any related drudgery.

Accordingly, it's time for businesses to take the security of their Web applications more seriously, and that begins by building more secure applications. For help, Jerry Hoff, VP of the static code analysis division at WhiteHat Security, offered these six starting points for anyone involved in managing a software development team:

1. User inputs are not your friend.
"This will sound like it's for developers, but everyone needs to understand that user inputs are not your friend," said Hoff via phone. Today, many sites--Yelp, Salesforce.com, Facebook, LinkedIn--are predicated on accepting many different types of content from users, including text, images, and uploadable attachments. But all of that user-supplied content also can be used by a crafty hacker to try and exploit the underlying Web application. Accordingly, "the more user input you're going to be collecting, the more work that will potentially need to be going into securing this input," he said.

2. Know which vulnerabilities will compromise you.
"Not just for developers, but for all people involved in developing Web applications, you need to have some proficiency with the top issues affecting Web applications," said Hoff. Accordingly, he recommends reviewing the Open Web Application Security Project (OWASP) list of the top 10 vulnerabilities currently affecting Web applications.

[ Read iPad App Allows Single Sign-On For Enterprise Apps. ]

Likewise, he recommends that managers--and their managers--begin holding everyone accountable for ensuring that each of the top 10 threats gets mitigated for every Web application that gets built. Finally, if the top 10 list sounds too dry, he recommends reviewing his multimedia OWASP Appsec Tutorial Series, available for free via YouTube.

3. Understand security controls in your languages.
"If you're working in a particular language--even if you're a manager--you should know the security controls for that platform," said Hoff. That goes for PHP, Java, .NET, or any other language being used. Each has its nuances, and some will offer better out-of-the-box security, but the important step is to ensure that everyone involved in building and approving a Web application understands how to stop exploits such as SQL injection and cross-site scripting attacks, and has the right development or code-checking tools to help. "That should be like a seatbelt or airbag that's already built into cars. They should just have that as part of their toolkit."

4. Never write your own security controls.
"If you're a manager or stakeholder, tell your developers: 'Don't write your own security controls, because you will fail,'" said Hoff. "If you're not someone who studies security 24/7, then you will make an assumption and miss something you think you've covered." Accordingly, he said it's essential to provide developers with a list of approved security controls that will mitigate every exploit in the OWASP top 10, as well as to give them the training they need to use those controls properly. "Now the top 10 is not an exhaustive list of vulnerabilities, but if you do that, you've at least gotten started."

5. Create a security community emissary.
Although the information security community might seem like a bit of an insider's club, Hoff said there are a wealth of resources on offer, and businesses would do well to ensure that at least one of their developers or managers is tasked to play Web application security champion. Resource-wise, there is an OWASP one-to-one mailing list, started by Mozilla's director of security assurance, Michael Coates, "which very few people leverage, which has hundreds of experts standing by," said Hoff. In addition, he said there are local OWASP chapters in cities around the world--"everywhere from New York to South Africa," meaning there are free and often local resources for getting answers to Web application security issues.

6. Apply security controls consistently.
Finally, "to be secure, you've got to be consistent," Hoff said. "As an attacker, they only have to find the one place where you don't have a security control, and that's the one place you'll be attacked." Preventing that from happening means applying security throughout the development of your software, "and that requires securing the software development lifecycle, or SDLC," he said.

Every company's SDLC program will be different, and security controls can be added in different places or handled in different ways, yet still be effective. "My advice is to decide what those are, and to be consistent," said Hoff. For creating more secure Web applications, whether it's training, standards, awareness, or controls, "consistency is the key," he said.

Mobile employees' data and apps need protecting. Here are 10 ways to get the job done. Also in the new, all-digital 10 Steps To E-Commerce Security special issue of Dark Reading: Mobile technology is forcing businesses to rethink the fundamentals of how their networks work. (Free registration required.)

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
MichaelC543
100%
0%
MichaelC543,
User Rank: Apprentice
1/17/2014 | 8:31:12 AM
Great LIst
We see many organizations challenged by the speed at which their code is changing and the sheer volume of those changes, both in custom code and libraries (over which they have little control).  All of these factors are increasing the rate at which security bugs are introduced into production undetected.

Continuous software delivery really demands continous and automated security analysis of issues brought up in your article.
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-4262
Published: 2014-07-28
svnwcsub.py in Subversion 1.8.0 before 1.8.3, when using the --pidfile option and running in foreground mode, allows local users to gain privileges via a symlink attack on the pid file. NOTE: this issue was SPLIT due to different affected versions (ADT3). The irkerbridge.py issue is covered by CVE-...

CVE-2013-4840
Published: 2014-07-28
Unspecified vulnerability in HP and H3C VPN Firewall Module products SECPATH1000FE before 5.20.R3177 and SECBLADEFW before 5.20.R3177 allows remote attackers to cause a denial of service via unknown vectors.

CVE-2013-7393
Published: 2014-07-28
The daemonize.py module in Subversion 1.8.0 before 1.8.2 allows local users to gain privileges via a symlink attack on the pid file created for (1) svnwcsub.py or (2) irkerbridge.py when the --pidfile option is used. NOTE: this issue was SPLIT from CVE-2013-4262 based on different affected versions...

CVE-2014-2974
Published: 2014-07-28
Cross-site request forgery (CSRF) vulnerability in php/user_account.php in Silver Peak VX through 6.2.4 allows remote attackers to hijack the authentication of administrators for requests that create administrative accounts.

CVE-2014-2975
Published: 2014-07-28
Cross-site scripting (XSS) vulnerability in php/user_account.php in Silver Peak VX before 6.2.4 allows remote attackers to inject arbitrary web script or HTML via the user_id parameter.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Sara Peters hosts a conversation on Botnets and those who fight them.