Security in Akara
Akara is a platform to facilitate RESTful services, so for the most part its inherent security issues are the same as those associated with REST architecture overall. Of course service implementations can and will introduce all manner of security issues, but this discussion focuses on matters relevant to Akara's core architecture, and security support Akara provides.
Security problems from REST anti-patterns
Most of the potential for security of REST lies in its simplicity, but this is does not always obtain in practice. For example the idea that GETs are "safe" (side effect free) is often violated by the likes of parameter-driven GET requests that modify or even resources. Akara seeks to provide enough tools to the developer to avoid this anti-pattern so that simple but effective coarse-gained security can be applied at the HTTP method level.
See also: slide 27 of XTECH07
Common attacks using tainted input include SQL and XPath injection, denial DOS from oversized parameters, the "billion laughs" attack from format conventions such as XML which can trigger cascading inputs, etc.
All these issues point to a single lesson: know where data is coming into your service, and in what cases this data might be coming from sources outside your close control.
Akara emphasizes identifying all the various data sources into a system, and the declaration of rules for these data sources. This can be done imperatively, but Akara supports a declarative style. One of the less obvious benefits of this declarative approach is that it serves as a flag for developers and maintainers of the system as to the data paths in the system, making it a bit easier to track how changes affect security.
See also: slide of XTECH07
HTTP Parameter Pollution
Akara does provide basic protection against HTTP Parameter Pollution. The @simple_service decorator by default forbids duplicated GET parameters.
The URI Jail
Similar to the concept of a chroot jail, Akara supports the concept of a URI policy manager. You can easily create a URI handler that allows you to register simple rules for URIs whose invocation is permitted. You could, for example limit to a set of base URIs, or you could set a policy to disable recursive redirects or or abusive patterns.
The ability to audit service interactions is an important part of security, which Akara, like many other server platforms supports with logging tools that capture protocol basics and can be extended with information in the application space.
In general Akara builds on other components and avoids reinventing wheels for protocol level security. This is a complex topic which includes:
- HTTP user authentication. Usually in REST this is a matter of HTTP Basic or HTTP Digest or signatures in the form of SSL certificate-based mutual authentication, available through a mixture of Python stdlib features and WSGI middleware.
- Authorization. This is a matter of determining whether the authenticated user shall be authorized for the service invocation. Approaches range from simple user/group-based ACLs available through WSGI middleware to the likes of SAML (what is the state of usable SAML implementations for such cases?)
- Data integrity (protection from snooping and man-in-the-middle attacks). The usual approach is SSL encryption. Protection for some man-in-the-middle attacks, such as replay attacks should be augmented in the application level, e.g. by managing session state sequence.
- Non-repudiation. The usual approach is the association of signatures/certificates (associated at the point of authentication) with service invocation.
Cross-site scripting attacks (XSS)
XSS attacks are generally a question of what script is applied by the client, and so not directly a matter for the Akara server.
Notes on application-level security
application-level security is beyond the scope of this document, but here are a few useful pointers
Amazon's security model is often praised as a good model for apps built on REST
"Meet skipfish, our automated web security scanner" - "Today, we are happy to announce the availability of skipfish - our free, open source, fully automated, active web application security reconnaissance tool."
Unfortunately much discussion of security in REST focuses on SOAP vs REST rather than fresh, focused coverage.
Some thoughts about SOAP versus REST on Security—REST is so much simpler on so many levels, and with simplicity comes a foundation of greater security
"Security for REST and Web 2.0", Presentation—Discusses what REST is, how REST is different from SOAP (in theory and practice), applying security to REST, security vulnerabilities of REST, how Amazon and Google approach REST security (a neat but very broad summary of AWS security, slides 33-37), reference architecture to protect both REST and SOAP, why XML firewalls are not enough and unified protection for REST and SOAP. Note, a presumably older version of this preso is http://www.vordel.com/downloads/rsa_conf_2006.pdf
In the value of REST's transparency: "A network admin [of a SOAP service] just sees POSTs and cannot understand the purpose of the traffic without looking into the SOAP messages themselves"
"Message Level Security and REST"—Frankly a sobering discussion
- There was an expat bug that affected 4Suite, and was patched by a variety of vendors: