App And Database Security: Two Halves Of A Whole

Limit application privileges to the database and sanitize input to improve data security

Data security, application security, and database security are like pieces of a puzzle -- different yet still dependent on one another to reach true completion. When they fail together, attack methods such as SQL injection have a far greater impact on an organization. In order to limit the scope of attacks, developers and DBAs need to acknowledge their roles in the process and work together to ensure that Web applications arent exposing sensitive databases.
This starts by understanding how much the current Web app phenomenon has opened up once-closed databases.
The days of static content Web sites are a distant memory, and every Web site or Web-based application today is back-ended by some kind of database, whether it’s your bank, your cloud CRM service, your mobile devices app-store, your favorite online shopping site, or your photo collection and blog, says Joe Levy, CTO of Solera Networks. The front-end application and the back-end database are inextricably bound in our current model, and one simply would not exist without the other.
According to Levy, one of the biggest weaknesses in this model is when the pathways to data arent properly controlled.
We expect that the Web application is the sole interface for human interaction with the data, and that an API is the sole interface for machine interaction with the data, he says. If this is not the case, then there might be insufficient controls of the pathways to the data, and that would be one very basic potential vulnerability. Even if access methods are well-defined, there is still a virtually unlimited number of ways that applications can fail to properly defend their databases. The fact is that the rule of least privilege shouldnt be instituted for only end users. It should also be applied to the applications themselves, says Chris Eng, vice president of research for Veracode.
All too often, applications are granted excessive privilege to databases that they dont need to operate, he says, explaining that the risks are amplified when multiple applications are granted access to databases used by other applications they dont necessarily need to be tied to. Those types of scenarios give patiently methodical hackers the opportunity to worm their way through a wider range of systems and data.
[Whats the best way to provision database users and control access to sensitive data? See
Analyzing Data To Pinpoint Rogue Insiders
.]
Eng says that developers and DBAs have to come up with a better system for tying the applications into databases.
It makes sense to chunk it out into better granularity where this application may have only read-only rights or may only have access to this certain table, he says. People dont do that now because they figure it is just easier to grant as much access as possible so you dont impede the development cycle or application functionality.
If they are given pushback, DBAs have the power to take the drivers seat in this interaction by not giving carte blanche to the developers.
The DBAs can just simply not allow so much access to be granted, Eng says.
In order to prevent the long arm of hackers from taking advantage out of inevitable Web application vulnerabilities, DBAs also have the power to institute other mitigating controls.
Until we achieve the lofty goal of fully homomorphic encryption -- where operations can be performed on encrypted data without having to actually decrypt, and thus expose, the data -- our next best bet is to move toward much broader adoption of database encryption, masking, or tokenization. Although this still often requires the data to be decrypted, it provides some defense against the wholesale theft of database contents, says Levy, who adds that, continuous monitoring of all application-layer and database-layer communications will help to quickly identify and resolve problems, and to accurately determine the scope of any security event.
But as Eng puts it, the onus is not just on the DBAs.
Developers definitely need to shoulder their share of the responsibility, too, he says.
One important way they can do that is to do a better job of scrubbing user input so they can prevent hackers from having their way with the database information through attacks like SQL injection.
It is simply unforgivable at this point for any application to not be providing adequate input sanitization, Levy says. That this is still one of the main causes of breaches a decade after the problem was well-understood is insanity.
Levy recommends organizations start using widely available pen-testing applications. And though Web application firewalls are a good way to mitigate risks, he warns developers to stop using them as a crutch to excuse them from not embedding proper validations in their applications.
Since waterboarding is neither torture nor unconstitutional, it should be considered as treatment for developers who do not properly sanitize inputs, he says.
Have a comment on this story? Please click Discuss below. If youd like to contact
Dark Readings
editors directly,
send us a message
.

Last News
▸ ArcSight prepares for future at user conference post HP acquisition. ◂ Discovered: 07/01/2025 Category: security	▸ Samsung Epic 4G: First To Use Media Hub ◂ Discovered: 07/01/2025 Category: security	▸ Many third-party software fails security tests ◂ Discovered: 07/01/2025 Category: security

**Cyber Security Categories**
Google Dorks Database	Exploits Vulnerability	Exploit Shellcodes

CVE List

Tools/Apps

News/Aarticles

Phishing Database

Deepfake Detection

Trends/Statistics & Live Infos

Tags:
App And Database Security: Two Halves Of A Whole