When we talk about web application security, vendors often direct the conversation towards the two most obvious user-visible security aspects: SSL (secure sockets layer) or TLS (Transport Layer Security), and password security. They talk about the 128-bit or 256-bit encryption they use, or the password composition constraints they impose, e.g., a minimum of 8 characters or a mix of upper and lower case.
The fact is, however, that while SSL and password security are important, they are just one aspect of security. If you are serious about security, you should look at the widely-respected OWASP Top Ten, a list of the most common security vulnerabilities in web applications. Of course, no system is perfectly secure, but Apsona’s architecture is designed to guard against most, if not all, of these attack vectors.
Two of the most common techniques used to crack web applications are SQL injection and cross-site scripting. The former technique relies on the fact that there is often a very direct correspondence between the web app’s SQL queries and the values of parameters submitted from the browser. So the attacker injects carefully-chosen SQL snippets into the values of request parameters. This can result in the application’s providing the attacker with database content (such as user names and passwords) that should not be exposed.
Apsona’s design uses several counter-measures to prevent such attacks. For one, it uses an intermediate metadata layer that maps user-level tables and columns to the actual database tables and columns. This layer provides two benefits: one, that it can be designed to target to any database, even to existing databases, so that (for example) we can create a user-level vocabulary of terms and concepts that are completely different from the database tables. For instance, we can have user-friendly table names such as Customer and Product that are mapped to more cryptic database table names like cw_cust or cw_prdt, thus improving the user experience. A second benefit is that the database nomenclature is completely hidden from the user layer, and is looked up via a run-time cache in the application. So there is no way for an attacker to create SQL snippets that use the names in real database to get at its content.
Apsona also guards against cross-site scripting in several ways. First, we ensure that we don’t fetch scripts from outside the Apsona domain. Second, we only use simple JSON, not the full JavaScript language, as the data interchange layer. And we avoid the most common pitfall that leads to scripting attacks — the JavaScript eval function — by explicitly parsing the JSON.
Another aspect of security is tenant data safety. Multi-tenanted or multi-hosted systems are sometimes implemented with one large database containing the data from all customers, and SQL filtering is employed to restrict the data for each customer based on their login credentials. This approach runs the risk that, if the SQL queries are not carefully coded, data from one customer can be exposed to other customers.
In Apsona, however, we dedicate a separate database instance for each application. Moreover, the code that processes a particular request is only given a single connection, to the one database for the application for that request. So there is no way that the code can access data from other databases, even if it were compromised. This idea of using multiple database instances gives us an added benefit: The speed and performance for a particular user is governed entirely by their own database, so a user with a small amount if data is not unnecessarily penalized because of their data residing in a large database, unlike with other vendors.
We have taken great care in designing Apsona’s architecture to be as secure as possible. We would be delighted to hear your comments.
