Securing remote JSON Web Services
When: 23 September 2014 @ 1400 GMT
Led by: Tomáš Polešovský
In this session, we'll explore how to create and consume JSON web services using secure methods to provide anonymous and authenticated access to your custom JSON web services. Topics you will learn:
- Creating public services as well as services that requires authentication
- A standard approach to authorization
- Authentication using
p_auth
token and built-in Basic/Digest authentication - Using services from outside using Cross-origin Resource Sharing spec
- Creating secure built-in portlet services using portlet's resource phase
- Overview of creating custom token authentication, API keys, filtering resources available and adding API connection limits
Some additional definitions and reading before the session will help you understand some of the key concepts:
-
p_auth
- A Liferay portal (Anti-)CSRF token included in URLs and HTTP requests to help prevent Cross-site Request Forgery attacks - CSRF - Cross-site Request Forgery - A malicious attack targeting existing user sessions where the attacker force an unsuspecting user's browser to perform actions in the vulnerable web application without the user's approval or knowledge. For example:a user is authenticated to a vulnerable site, and while still authenticated she visits a malicious page that sends a hidden request to the vulnerable site and changes or deletes the user's email address or phone number, opening them to other attacks. A Non-authenticated attack consists of placing the attack vector on a high-traffic site (e.g. on a poll or forum post) hosted by the vulnerable site, then anybody visiting the high-traffic site that votes in the poll can get attacked.
- CORS - Cross-origin Resource Sharing - A standardized way for JavaScript to read/parse responses from a site hosted on a different domain. It's replacement for JSONP. For example: a web application @ https://example.com uses JavaScript to exchange data with https://api.example.com. For this to work the API site must emit CORS HTTP headers to enable the application to read the data.
- Authentication - Proving you are who you say you are (your identity/credentials) to a web site. For example: Liferay checks that the provided login+password or SSO token is valid.
- Authorization - Access control used to validate user permissions to access a resource. For example: Checking whether a non-authenticated user is allowed to download a particular file
There are many guidelines with respect to securing sites. The most important ones relevant to securing APIs are:
- Use HTTPS to avoid interception and modification of requests/responses
- Where possible, allow authenticated access only, always perform permissions checks
- For errors return only messages + timestamps, stacktraces should go always only into logs
- Review access logs for HTTP 404 and 500 errors
- Read OWASP's REST Security Cheat Sheet
Basic setup requirements before the session:
- A running Liferay 6.2 installation (with no modifications needed)
- A development environment (like Liferay IDE) to be able to create and deploy portlets