When it comes to OWASP Top 10 vulnerabilities and best practices for web applications, the riskiest and most successful exploits in terms of valuable data extraction and system pwned are web injection flaws. Organizations have continually struggled to effectively manage vulnerabilities, including having adequate scanning and reporting mechanisms followed by functional remediation SLAs with the development staff. But there is one area where everyone is significantly more handicapped: user-generated content (UGC).
Internet consumers have become accustomed to social engagement features on virtually every website they visit. These user-generated content features on web applications (for example, creating a profile, asking a question, adding a picture, or entering comments) are challenging for developers and security administrators to manage because they leave them open to exploit if the input is not properly sanitized. These features are easier to manage if you’re developing the code in house. However, many organizations are opting to use third-party CMS and forum software (a lot of which is freeware or open source) that plugs into their site. Why re-invent the wheel when someone else has already done it?
The challenges with these software programs are twofold. First, enterprise vulnerability scanners have been slow to fingerprint the most widely used CMS and forum software. You can’t protect what you can’t see—and being at the mercy of your development staff to let you know something exists is never a position any security engineer wants to be in.
Second, only recently have market-leading tools such as WordPress begun to address their security flaws with CVE disclosures, security patches, and automatic update features. The challenge is that hackers have been hip to this game for a while and have created their own fingerprints and automated scans to detect such software and automatically exploit it in a relatively short period of time.
Throw Your Hands Up or Do Something About It?
Never give in. Consumers might not care anymore if their data is compromised (just take a look at the stock performance of some of the more notable security breaches in recent history), but security administrators still take pride in their work and owe the management staff their continual best effort. Egg on your face never feels good, and every time it happens, you can always pinpoint where you should have pushed harder.
This is not a winless game. Working smarter against the uphill battle of vulnerability management means implementing a web application firewall (WAF) to auto-mitigate your vulnerabilities. This does not mean your developers shouldn’t fix their coding flaws, rather it buys both parties time with incident response efforts and management communication—and it could potentially save your job.
In the event that you have a WAF in place and are hacked (likely, in the scenario where you have implemented the solution in monitoring/listen-only mode), the collection of the post data will be your primary evidence source that indicates how your application was exploited. This information is critical in your investigation and remediation efforts because you must always identify the “how” so you know “what” to fix.
WAFs are only as effective as the engineers who manage them. You can’t simply turn a WAF on using default policies without impacting legitimate traffic. Nor do WAFs come out of the box with custom policies for input sanitization, so you need skilled security engineers to manage the solution in partnership with the development staff. WAFs are also more effective when integrated with a web application vulnerability detection service such as WhiteHat Security, so the highest levels of your technology organization must buy into the solution. This is a budget use case you can win if you factor in the cost of a breach (largely determined by the data set you are protecting and record quantity), and the deductible of your cyber insurance policy. Note that your policy will likely increase significantly if invoked in a disclosure scenario.
Many organizations, especially those with high data protection requirements and low sensitivity for latency, are opting for WAF management services instead of managing the policies in house. WAF engineers can implement and fine-tune policies faster than an in-house engineer because they are dedicated to monitoring the solution and know the product inside and out.
A Day in the Life of a WAF Administrator
Continual management efforts shaping WAF policies are not typically driven by attacks, rather they are driven by application changes, especially in accelerated application development environments. A WAF administrator must review and analyze logs for policy violations and respond with changes that could permit legitimate traffic—or not, if they’re seeing false positives. If you don’t want your limited security engineering resources focused on managing policies to keep up with rapid application changes, and you can’t afford application performance hits or feature disruptions while waiting for a policy to get updated, it’s a good idea to look into outsourcing these operations to a managed service provider. When it comes to attack use cases, your WAF administrator should be making special alerts and configurations for attack types that appear like legitimate traffic to the WAF, such as brute force and bot/web scraping. Advanced administrators will develop custom signatures to protect against identified vulnerabilities for which out-of-box signatures do not exist.
UGC Best Practices
In regards to input sanitization flaws with user-generated content, you should only relax your policy—to allow approved content types in—within the particular user-generated content portion of the app. This introduces the least exposure to the app while allowing the business process to function. Some of the defenses applied against user-generated content (in line with OWASP guidelines) are as follows:
- Prevent file upload of executables
- Prevent *nix command-execution in the web application
- Prevent upload or execution of scripts in web forms unless specifically allowed
- Prevent file upload modification from an accepted file type to a non-accepted file type
- Strongly advise customer to not allow public Internet-access to the admin page
Conclusion
Community and social engagement features have become the online experience standard. When you allow users to create a profile, add a picture, ask a question, or enter a comment, they are adding to your website. It is your responsibility to ensure they cannot leverage this capability to inject malicious code. Consider it a cost of doing business online.
Implementing a WAF is a good first step to protect yourself, as long as it is properly configured and managed by your security engineers and development staff. Development involvement is critical so that web application updates can be made where needed and you inadvertently relax your policies to the point that they’re effectively disabled. Managed WAF services are a preferred alternative for some organizations because they provide around-the-clock monitoring and remediation by security experts and don’t require you to have the in-house expertise or redirect one of your senior engineers to manage it. Whatever approach you choose, it is effort well spent.
