Security in Formspider Applications

Formspider has a number of built-in countermeasures to help developers build secure applications. Implementing security best practices at the framework level, instead of application level, has multiple benefits:

1. Formspider Developers build applications with higher quality because they reuse the security best practices in every application they build by default.

2. Formspider Developers work more productively because they spend less time resolving security issues.

3. Applications built with Formspider pass security audits easier and faster.

Below is the list of OWASP Top 10 Application Security Risks along with a brief explanation on how Formspider helps developers to avoid them.

Injection
Formspider has security measures to prevent injection. In the framework source code Formspider always uses bind variables when running an SQL query. This prevents malicious code from being executed inadvertently. Using bind variables in SQL statement that relies on user input is considered the single most important protection from injection. This enables Formspider to provide safe API’s that developers can use in their applications.

Moreover, Formspider takes full advantage of PL/SQL, to prevent injection. PL/SQL is very well protected against injection by design because it natively compiles SQL. Therefore the need to concatenate strings to construct an SQL statement virtually disappears. Every SQL query in PL/SQL uses bind variables by design. It is not impossible to write queries with security vulnerabilities in PL/SQL (for example using execute immediate incorrectly) but one really must go out of his way to do so.

XSS
At the framework level, Formspider escapes all untrusted data automatically to secure applications built with it from XSS attacks.

Broken Authentication and Session Management
Formspider takes various measures to securely manage user authentications and sessions:

It provides a special API called api_session.authenticate, to provide a simple way for developers to securely authenticate a user session. Calling this API changes the key of the user session.

api_application.close can be used to terminate an application at any point in time.

The framework prevents access to an application from a second IP address as long as a user session is active from another IP address.

Formspider applications cannot be opened in an iFrame if they are called from a different domain.

Every servlet in the Formspider middle tier is only accessible by a valid session. No new servlets are written by developers during development of a new application. Every application uses the same servlets. This greatly reduces the management of servlet security.

Session ID is not shown in the URL string.

Developers can define a session timeout for each application which terminates the user session after a certain period of inactivity.

Insecure Direct Object Reference
Restricting access the UI components in the browser but not securing the corresponding resources in the server is a very common error made during web development with Javascript.

Formspider listens to every API call the developer makes to change a UI component’s state and takes the appropriate security action. For example, if the developer disables a button, Formspider automatically locks the button resource for the user session. Once the resource is secured, any user action coming to the server claiming to press the disabled button is considered fraudulent activity and Formspider automatically terminates the user session.

Developers don’t need to do any extra work for this security precaution to kick in. Every Formspider resource is secure by default.

Cross Site Request Forgery
Formspider creates new instance OID’s for its UI components every time a user opens a new session, making it virtually impossible for an attacker to predict these OID’s. Even though many users may be running the same application, the OID’s of each component is different for each one. This addition of hundreds of unpredictable tokens greatly helps Formspider developers to protect their applications from Cross Site Request Forgery.

Security Misconfiguration
Formspider middle tier installation allows acces to Get, Head and Post methods only. Formspider hides every error message raised by an application by default.

Insecure Cryptographic Storage
This vulnerability is beyond the scope of the Formspider framework

Failure to Restrict URL Access
Most web applications built with other frameworks expose hundreds if not thousands of URL’s to the outside world which need to be secured individually. Formspider has only a handful of servlets that are used by every application built with it. Since these servlets are properly secured by the framework, this vulnerability is virtually non-existent in the Formspider architecture.

Insufficient Transport Layer Protection
Formspider supports using SSL certificates.

Unvalidated Redirects and Forwards
Formspider applications run through a single URL. There are no forwards and redirects in them. For bookmarking, Formspider uses a randomly generated string that enforces the developer to evaluate the incoming bookmark value before sending the user to the correct screen.