Web Application Security + OpenID NWEN 304: Advanced Network Applications

Info ICT Careers fair on Friday Tech report out today Teaching evaluations Groups

Cross-site scripting (XSS) An input validation vulnerability. Allows an attacker to inject client-side code (JavaScript) into web pages. This is then served by a vulnerable web application to other users.

Reflected XSS The injected code is reflected off the web server – an error message, – search result, – response includes some/all of the input sent to the server as part of the request Only the user issuing the malicious request is affected StringsearchQuery= request.getParameter(“sear c hQuery”); … PrintWriterout= response.getWriter(); out.println(" "+ "Resultsfor " + searchQuery + " )"; User request: searchQuery= alert("pwnd")

Stored XSS The injected code is stored on the web site and served to its visitors on all page views – user messages, – user profiles, All users affected StringpostMsg = db.getPostMsg(0); … PrintWriterout= response.getWriter(); out.println(" "+ postMsg)"; pstMsg: searchQuery= alert("pwnd")

Solution for injection: santization Santizing all user inputs is difficult -- why? Sanitization is context-dependent – JavaScript user input – CSS value a:hover {color: user input } – URL value Sanitization is attack-dependent, e.g. – JavaScript – SQL Blacklisting vs. whitelisting Roll-your-own vs. reuse

Roll-your-own: example On Twitter if user posts twitter displays: Twitter’s old sanitization algorithm blocked but allowed “. What happens if somebody tweets: \u002fis.gd\u002ffl9A7')”/ Twitter displays: …

Roll-your-own: example Anyone putting mouse over such a twitter feed will run JavaScript that puts a similar mesage in their own feed. The actual attack used: "onmouseover=”…/ – Why the style part?

Roll-your-own: example This is what it looked like:

Reuse: example JQuery has built-in support.text() method for strings and.val() for input parameters. Escapes html code and prevents the browser interpreting a given string. -& becomes &amp -< ->

Now: OpenID Terminology: Identity Authentication Authorisation OpenID

Identity A set of attributes related to an entity Entity: Attributes: Name Address Sex Height Etc. Identity: Work, Personal, Private

Identity

Authentication Positive verification of identity Determines: What you know – pin/password What you have – token/cert/RFID Who you are – Biometric

Authorisation Authorisation determines whether an entity is allowed to perform a given activity Typically inherits from authentication Cases like OAuth let you access protected data (across domains) without having to re- authenticate the user

OpenID, OAuth, and OpenID Connect OpenID = Authentication Making sure the user is who they say they are OAuth = Authorisation Deciding what the user is allowed to do An “access granting protocol” More on this next time OpenID Connect = Authentication (but built on OAuth 2.0)

Password Management: Adobe # Count Ciphertext Plaintext EQ7fIpT7i/Q= j9p+HwtWWT86aMjgZFLzYg== L8qbAD3jl3jioxG6CatHBw== password BB4e6X+b2xLioxG6CatHBw== adobe j9p+HwtWWT/ioxG6CatHBw== djv7ZCI2ws= qwerty dQi0asWPYvQ= LqYzKVeq8I= PMDTbP0LZxu03SwrFUvYGA== photoshop e6MPXQ5G6a8=

OpenID 1.0/2.0 Started around 2005 Motivation: Users have accounts all over the Web User profiles are distinct Multiple passwords problem Goal: Apps/sites can leverage an OpenID provider: A third party authentication service Federated login Users have one account at the provider

OpenID 1.0/2.0 Decentralised mechanism for authentication OpenID protocol: describes authentication process OpenID: - It *is* a URI The user is in control and selects the URI - Pick a provider you trust, similar to - Your own domain (delegate process to another IP) - Have multiple identities OpenID Providers Google, Yahoo!, etc. Yourself – run your own server

OpenID 1.0/2.0 You can claim you own the URI You can prove you own the URI  You can use it to authenticate yourself on other websites  You don’t need to have an account on a new website It can also be extended to include profile information and claims

How it works XSRD (eXtensible Resource Descriptor Sequence): Format for discovery response Describes endpoint to send login requests Credit:

How it works The user authenticates with the openid provider: Example Google OpenID provider ?openid.ns= &openid.return_to= &openid.realm= &openid.assoc_handle=ABSmpf6DNMw &openid.mode=checkid_setup ns – protocol version (obtained from the XRDS) mode – type of message or additional semantics return_to – callback page the provider sends the result realm – domain the user will trust, consistent with return_to assoc_handle – "log in" for web app with openid provider Credit:

OpenID 1.0/2.0 Limitations Never really adopted Works for websites, but not native apps/mobile Difficult to implement (properly) URI’s are hard for many users to understand and remember Relies on XML

OpenID Connect Third iteration of OpenID Released 2014 An identity layer on top of OAuth2.0 Much more developer friendly Leverages standard TLS infrastructure + JSON+ REST= better interoperability and adoption Designed for mobile/apps etc. Scalable security: LaO1-04 Based on s

OpenID Connect

Next time OAuth and you.