One of the biggest threats to data integrity is the introduction of malicious content via SQLi (SQL Injection) attacks. Traditional database access methods don’t provide a lot in the way of validating requests and like HTML the vagaries of SQL allow for myriad ways in which a statement can be constructed – and thus exploited.

These vagaries, of course, are one factor in the reason why SQLi continues to plague applications and sites driven by user generated content. Another factor is certainly the number of touch points in application code where attacks might slip through. With every new SQLi technique comes the need to update every one of those touch points and ensure they can properly defend against the new variation or technique.

But service enabling data sources changes the point of entry. It centralizes access down to a single point of contact.

Joe McKendrick notes in a recent blog on a related topic (data quality and SOA):

Ash [Informatica’s Ash Parikh], who has been warning the industry about the quality of data — or lack thereof — surging through SOA-based infrastructures for some time now, says SOA data services open up many new avenues for connecting SOA with enterprise data management. “It’s much more than just data access,” he points out. “It’s making sure the data that is delivered is of the greatest quality.” [emphasis added]

If we expand “quality” to include “clean, untainted, and free of malicious content” then we’re pretty much on the same page.

SECURITY AND TRADITIONAL DATA ACCESS MODELS

Using traditional methods of database access (JDBC/ODBC/ADO.NET/PHP ADAPTERS) every time a developer wants to access the database they must:

1. Obtain a connection to the database

2. Construct the appropriate query

3. Execute the query

One assumes, of course, that prior to constructing the query that any user-supplied input is validated and any potentially malicious content either stripped or outright rejected.

Most web applications today are data-driven, meaning they require a database in which to store and retrieve content. These applications – and that includes blogs, content management systems, news sites, and social networking sites – may contain multiple queries on every page, meaning there are multiple points at which malicious content may be introduced into the system. Add-on the possibility of an API through which content may be added and you’ve increased again the number of potential “holes” through which an SQLi attack might be executed.

Service-enablement, on the other hand, effectively reduces the number of potential entry points through which an attack may occur. It reduces the attack surface.

In a service-enabled database access scenario, the applications still make the same number of “connections” because each query is designed to perform a specific task , but instead of those queries going directly to the database they are actually made to a service interface instead. It is the service interface that then handles database connections, constructs the query, and executes the query on behalf of the client application.

There are two possible security outcomes to this scenario.

1. Overall security is improved. Because there are fewer interfaces to secure the process of validating and further detecting potentially malicious code will be more thorough. Reducing the number of places in which these checks must occur also reduces the potential to “miss” a touch point when implementing security processes. Protection against SQLi is shared by all applications, so if security at the interface is properly implemented it will be beneficial to all applications using the service.

2. Overall security is degraded. Because the data access service interfaces are shared across all applications, any vulnerabilities are shared by all services utilizing the interfaces. It is also possible that the use of service-enabled interfaces may introduce additional avenues of attack. Service-enablement via SOAP/HTTP brings with it all the security vulnerabilities associated with XML and SOAP. Service interfaces are also publicly accessible, so authentication and authorization are paramount to successfully securing such implementations. Weak or easily breakable authentication schemes can lead to compromise. If the services are publicly accessible this could be an even higher concern.

ENSURING THE BEST POSSIBLE OUTCOME

It certainly appears at first glance that perhaps the possibility of a negative outcome – because of the impact to multiple applications –outweighs the potential benefits of improving security. But the change in architecture affords the opportunity to provide additional security around the service (as well as scaling benefits that are not typically associated with databases) than can tip the scales of benefits versus risk to the side of improving security.

1. A reduction in the number of entry points at which SQL queries are constructed from user input increase the resources that can be applied to the security of those interfaces. Fewer entry points affords a tighter focus on applying secure coding practices against the OWASP Top Ten. Testing against vulnerabilities, too, becomes easier and potentially more thorough.
   
2. Adding a data service layer, usually enabled by HTTP, enables the leverage of existing technology to secure the messages and protocols between the application server and the data services. A web application firewall can provide additional security scans on the services in real time as well as provides protection against (un)intentional denial of service attacks against the service. XML-related capabilities in WAF solutions can also address the potential introduction of XML specific vulnerabilities to the architecture, as well as offering support for authentication and authorization and encryption/signing of requests.
   
3. Moving data services to its own tier separates the tiers more completely and provides better agility for development. If a new vulnerability is discovered, for example, it need only be addressed in a limited, well-known set of services rather than across all applications that may be vulnerable. This can reduce the time to fix vulnerabilities or add new functionality to the data tier.

Service-enabling data sources is an architectural change that should not be executed upon lightly. It affects all other applications that rely on the data source, and introduces another layer into the architecture that may or may not make it more complex. Moving to such an architecture can be beneficial and can drastically improve security and decrease the likelihood of a successful SQLi attack. But if not entered into with the proper motivation to ensure the services are secured, tested, and protected against other security vulnerabilities it is possible that such an architecture could degrade your overall security posture and make it more likely that an attack will succeed.

Careful consideration regarding the dedication of resources and testing of data services is required before embarking on such an initiative. Collaboration between architecture, network, and development teams is required to design the service and its supporting application infrastructure in such a way as to ensure the change is a net positive for the entire organization.

Related blogs & articles:

• OWASP Top Ten Project
• Data services may help address a major SOA unknown – data quality
• ODBC vs newer methods for database management over the Internet
• Virtualization Changes Application Deployment But Not Development
• When Is More Important Than Where in Web Application Security
• Putting a Price on Uptime
• Web Application Security at the Edge is More Efficient Than In the Application
• Excuse Me But Is That a Gazebo On Your Site?!'

Read the original blog entry...