Micro Focus is now part of OpenText. Learn more >

You are here

You are here

Top web app vulnerabilities: How to secure your pipeline

public://webform/writeforus/profile-pictures/company-leadership-see-more-shivajee-samdarshi.jpg
Shivajee Samdarshi Sr. Vice President of Engineering, WhiteHat Security
 

Applications are fast becoming the largest attack surface in enterprise IT security. They are the most publicly accessible entrance to an organization's IT ecosystem, and are the way in which most customers complete communications and transactions.

Because the information applications store, transfer, and process is extremely valuable to hackers, attacks against applications (web, mobile, and APIs) have seen an unprecedented increase in scale, intensity, and sophistication.

But where should organizations start to look for vulnerabilities in their existing web applications, and where should they focus when designing their new ones? Here are the key takeaways from WhiteHat Security's Application Security Statistics Report.

Information leakage

The report suggests that information leakage is the most prevalent web app vulnerability, with an occurrence likelihood of 37%. It affects about half of all web applications today. Information leakage exposes data that could facilitate application attacks, potentially aiding hacker attempts to breach security measures.

Examples include leaked email addresses, file system structures, database configurations, and session/authentication tokens. It’s a key issue today because complex, in-depth software coding means mistakes that lead to information leakage are easy to make and can remain hidden for a long time before being spotted.

Cross-site scripting (XSS)

XSS targets the client side of an application to execute a malicious script in the user’s browser. Major websites such as Google, Yahoo, and Facebook have been affected, and our research suggests that there is a one in three chance of XSS happening to a website in your organization, too. Hackers exploiting this vulnerability can steal data, run malicious code, deploy a phishing scam, or take control of a user session.

XSS persists because the majority of modern websites have to be interactive, with the ability to accept and return user data in real time (imagine how poor the online banking experience would be if users couldn’t interact with their account information, such as transactions, in real time).  But this functionality means hackers can also interact with application processes, exploiting vulnerable code to bypass traditional perimeter security defenses. To protect against this, user input/data must be properly encoded and sanitized.

Content spoofing

Content spoofing allows attackers to control the content an application displays to the user. Hackers could, for example, deface a web page, mimic an authentication screen to steal user passwords, or display an error message to compel some other action that would compromise sensitive user data. Therefore, developers must always have their guard up when taking text from an input request to ensure that data is properly displayed as data, not as content.

Insufficient transport layer protection 

Weak ciphers, certificate misconfiguration, or known vulnerable protocols have been exploited in zero-day attacks such as Poodle, Shellshock, and HeartBleed—making it a critical but tricky error to fix. Developers must properly maintain protocols, ciphers and certificates in live applications to keep them safe and up to date, while balancing security and usability requirements.

Reappraise your application development practices

To outthink attackers and prevent these kind of attacks, organizations need to re-examine their approaches to software development, particularly the notion that developers should just be able to code securely.

Developing applications without attention to security at each stage of the software development lifecycle (SDLC) won’t cut it, and passing an application on to a few highly trained individuals at a later stage (even with support of a standalone static application security testing, or SAST, tool) to investigate code for security risks won’t keep hackers at bay.

Instead, to fully understand an application’s weaknesses and overall security standards, secure more of your source code throughout the entire SDLC, with development, operations, and security teams (DevSecOps) working together at each point.

Working in this way means, however, that even some of the second-generation, cloud-based SAST tools still used in many organizations can't provide the necessary security checks and balances. Security analysis with these kinds of tools is not continuous, so applications must be nearly complete before any analysis will be useful.

As a result, security advice reaches the developer too late in the development cycle, leading to missed production deadlines, and unsecured code making its way into deployment and everyday use.

Secure your software throughout the SDLC

So what’s the alternative? How should businesses keep application security at the forefront during each phase of the SDLC? Here are a few suggestions to get you started:

1. Training. Everyone involved in web application development should receive basic security training and regular updates on best practices.

2. Requirements. If sensitive customer data is to be collected and stored by the application, requirements on how the data should be encrypted, both in transit and at rest, should also be established at an early stage.

3. Design. Once the application requirements are captured, an architecture is created that should correspond to the software requirements. At this stage, necessary security controls should also be identified and planned as part of the application design.

4. Implementation. Developers should receive security feedback while they are coding. This feedback should be done as early and often as possible. Because this phase is usually the most labor-intensive, it's a good idea to continuously run automated security assessments so you can address issues in near real time.

5. Quality assurance: New code needs to be tested before it goes into a production environment, to ensure that it functions as expected. While most organizations test for functional requirements at this stage, they should also test for security requirements.

6. Production. Finally, in the deployment phase, continuous testing is vital to maintain security assurance and to protect the application where most attacks occur. Also, updates to production applications can introduce new flaws, so any code updates should be subjected to source, QA, and production testing.

No single measure will measure up

There is no silver bullet for implementing foolproof application security. The best application security programs are ones that combine forces, using the right tools at the right inflection point in the SDLC. Raising awareness around application security among development organizations is an essential aspect of rolling out even a simple application security program.

Businesses should adopt dynamic application security testing (DAST) alongside their existing SAST tools to automatically examine applications for key vulnerabilities at every stage of their lifecycle.

The key takeaway for organizations in all industries and at all stages of maturity is that no single measure is sufficient to guarantee the security of web applications and the data you manage.

Web applications and security risks are both constantly changing. To stay secure, make security a priority; give it the resources it needs in terms of people, time, training, and budgets; and look at security as a job that’s never done.

Setu Kulkarni, vice president of product and corporate strategy at WhiteHat Security, contributed to this post.

Keep learning

Read more articles about: SecurityApplication Security