Download to read offline
Uploaded byIgor Bossenko
Webapp security (with notes)
The document discusses various authentication mechanisms for securing web communications, including HTTP Basic Authentication, API keys, and OAuth. It highlights the importance of securely storing passwords and tokens, differentiating between user authentication and identification. OAuth is presented as a solution for allowing third-party applications access to user data without sharing passwords, with a focus on its evolution and improvements in OAuth 2.0.
More Related Content
Similar to Webapp security (with notes)
Webapp security (with notes)
- 1. To find out what problems we have, tried to repeat of Web security basics first. 1
- 2. • It’s easiest to use “HTTP Basic authenAcaAon” that most websites use. Used for protect resource. The advantage of using this technology is that nearly all clients and servers support it. There is no special processing required, as long as the caller takes reasonable precauAons to keep the password secret. • Usernames and passwords also work well for applicaAon-‐to-‐applicaAon communicaAons. Username used for caller idenAficaAon. The trick -‐ the password must be stored securely, and if it’s being used by a server, where do you store it? If you are running an applicaAon server that uses a database, you already have solved this same problem, because the database usually requires a password too. BeIer applicaAon server plaJorms include a “credenAal mapper” that can be used to store such passwords relaAvely securely. • TwiIer simplifies things for their users by using usernames and passwords for API authenAcaAon. Every Ame a user starts a TwiIer client, it either prompts for the username and password to use, or it fetches them from the disk (where it is somehow scrambled or encrypted where possible). So here it makes a lot of sense to have the same username / password for the TwiIer API that it used for the web site. 2
- 3. API key used for caller idenAficaAon. 3
- 4. Take Yahoo and Google maps – they are fairly open. They want to know who you are but they aren’t concerned what address you are looking up. API key idenAfy the caller. The API key lets them idenAfy (most likely) who is making a API call so they can limit on the number of requests you can make. IdenAty is important here to keep service volume under control. An API key gives the API provider a way to (most of the Ame) know the idenAty of each caller to maintain a log and establish quotas by user (see the last secAon). Check IP addresses of caller (legacy) is analog of IP check during Basic Authen:ca:on. 4
- 5. Large service providers offer user-‐friendly interfaces to work with the public API 5
- 6. Usually public site provide console for API-‐Key generaAon 6
- 7. So they use an “API key” to establish idenAty, but don’t authenAcate or authorize. So if you use someone else’s API key, it’s not good but not a serious security breach. 7
- 8. For future purpose we introduce term -‐ Nonce 8
- 9. Key authenAcaAon is the process of assuring that the key of "person A" held by "person B" does in fact belong to "person A" and vice versa. This is usually done aZer we assume that the keys have been shared among the two sides over some secure channel, although some of the algorithms share the keys at the Ame of authenAcaAon also. Symmetric cryptosystems provides method of encrypAon in which for encrypAon and decrypAon used the same cryptographic key. The encrypAon key must be kept in secret by both parAes. In terms of the OAuth login analogue called Key, and password analogue -‐ Secret. The situaAon when the Secret is known only to the sender and the recipient called Shared Secret. The weakness of this soluAon is possibility to calculate key, if you now both unencrypted text and encrypted text!!! 9
- 10. This is the problem of assuring that there is no man-‐in-‐the-‐middle aIacker who is trying to read or spoof the communicaAon. There are various algorithms used now-‐a-‐days to prevent such aIacks. The most common among the algorithms are Diffie–Hellman key exchange protocol, enables two or more parAes to obtain a shared secret key using unprotected from listening communicaAon channel. The resulAng key is used to encrypt further exchange using symmetric encrypAon algorithms. 10
- 11. Encrypted with one key -‐> decrypted with the other A public key infrastructure (PKI) is a set of hardware, soZware, people, policies, and procedures needed to create, manage, distribute, use, store, and revoke digital cerAficates. 11
- 12. AuthenAcaAon with signature is secure! But we must use Nonce for protect from replay aIacks. Nonce usually included into signature Now you know all required theory and you are ready to write your own bicycle!!! Pay aIenAon to the aIributes of the query:X-‐API-‐KEY, X-‐SIGNATURE, X-‐NONCE. Non-‐standart soluAon. Every company make own implementaAon. Amazon was first (and probably the best)! 12
- 13. hIp://docs.aws.amazon.com/AmazonS3/latest/dev/ RESTAuthenAcaAon.html#ConstrucAngTheAuthenAcaAonHeader So custom secure soluAon without OAuth is possible. But all this soluAons non-‐standardized! You must read manuals every Ame for a long Ame!!! 13
- 14.
- 15. OAuth was designed to solve the applicaAon-‐to-‐applicaAon security problem. The idea of OAuth is that it gives the user of a service or web site a way to condiAonally grant access to another applicaAon. OAuth makes it possible for a human user to individually grant other APIs or sites access to their account without sharing their actual password. It works by giving a “token” to each API or site that will access the account, which the user may revoke at any Ame they wish. 15
- 16. User: end-‐user of applicaAon. Consumer: applicaAon/form processing received data. Service Provider: data provider; such as GMail, providing access to protected resource. Protected Resource: real resources such as personal data or contacts from your Gmail address book. Provider API: API GMail, allows any script to get contacts from the address book Gmail. Task of OAuth -‐ make User was able to work on the service Consumer with the protected data provided by the Service Provider (Gmail) OAuth founda=on • App = Consumer + API access • Token = Key + Secret One of the principles OAuth states that no secret keys should not be passed in a query open. Therefore, the protocol uses the term Token. The token is very similar to a pair of username + password : login -‐ public informaAon and password -‐ known only to the transmilng and receiving side. In terms of OAuth login analogue called Key, and the analogue password -‐ Secret. SituaAon where Secret is known only to the sender and the recipient , but over 16
- 17. Fundamental: OAuth = Fetch Request Token + Redirect to Authoriza=on + Fetch Access Token + Call API Steps: 1. Fetch Request Token (inner query). Consumer-‐script refers to a Request token URL Provider-‐as for example, api.rutvit.ru / oauth / request_token. The request is transmiIed Consumer key -‐ «login applicaAon", and the request is signed using the Consumer secret -‐ «applicaAon password" which protects it against forgery. In response Provider generates and returns a "filled with garbage" token called Request Token. It sAll is useful to us, so we need to keep it somewhere -‐ for example, in the session variable $ S_REQUEST_TOK. 2. Redirect to Authoriza=on (via redirect the browser). Now that our applicaAon has a unique Request Token. Requires the user to obtain permission to use this token, ie ask him to authorize Request Token. Consumer redirects the browser to a special Authorize Provider URL for example, api.rutvit.ru / oauth / authorize. In the parameters passed Request Token Key. Provider displays the authorizaAon form for your user if he is logged in, the browser redirects back. Where is it? And we give this parameter oauth_callback. 17
- 18. 3 . Fetch Access Token ( inner query ) . So, does he returned to our applicaAon aZer a series of redirects. This means that authorizaAon on the Provider was successful, and Request Token is allowed to work. However, the OAuth token for each security has its own strictly limited purpose. For example , Request Token is used only to obtain confirmaAon from the user, and for anything else . To access the resources we need to get a new token -‐ Access Token -‐ or as they say , “Request Token exchange on Access Token». Consumer refers to Access token URL -‐ for example , api.rutvit.ru / oauth / access_token, -‐ and applies for the Access Token him return it available Request Token-‐ a. Request digitally signed on the basis of Request Token secret. Provider generates and returns the Access Token, filled with "garbage ." He also marks in their tables that this Access Token-‐ and allowed access to API. Our applicaAon needs to save at Access Token, if it is going to use the API in the future. 4. Call API (inner query). Well, now we have the Access Token, and we can pass it when calling the key API.Consumer generates a request to the API Provider-‐a (for example, using the POST-‐request under REST-‐ideology). The request is transmiIed Access Token Key, and it is signed using the Shared Secret that token. Provider processes the API-‐call, and returns the data to the applicaAon. 18
- 19.
- 20.
- 21. 1. ApplicaAon-‐Consumer receives Request Token. 2. The user is redirected to the site of the Service Provider and authorizes there Request Token. 3. ApplicaAon-‐Consumer exchanges Request Token for Access Token. 4. ApplicaAon-‐Consumer applicaAon makes authenAcated requests to the API service. Very good security! If we use verified secret key storage then we got same level of security as xRoadLevel is 21
- 22. In reference to digital security, nonrepudiaAon means to ensure that a transferred message has been sent and received by the parAes claiming to have sent and received the message. NonrepudiaAon is a way to guarantee that the sender of a message cannot later deny having sent the message and that the recipient cannot deny having received the message. NonrepudiaAon can be obtained through the use of: digital signatures-‐-‐ funcAon as a unique idenAfier for an individual, much like a wriIen signature. confirmaAon services -‐-‐ the message transfer agent can create digital receipts to indicated that messages were sent and/or received. Amestamps -‐-‐ Amestamps contain the date and Ame a document was composed and proves that a document existed at a certain Ame. AuthenAcaAon is a technical concept: e.g., it can be solved through cryptography. Non-‐repudiaAon is a legal concept: e.g., it can only be solved through legal and social processes (possibly aided by technology). 22
- 23. • OAuth needs secret key. xRoad public/private cerAficates may be used • xRoad store cerAficates in secure server (turvaserver), in case of OAuth it may be any verified cerAficate storage, such as LDAP • xRoad organizaAon and procedures are very good!!! • xRoad provide messaging API • xRoad required special soZware for secure server, Oauth don’t require • xRoad is Estonian standard, OAuth is internaAonal standard OAuth is same secure and can replace xRoad in interna=onal projects (NB! This is Igor Bossenko personal posi=on and currently doesn’t reflect Nortal point of view!!!) 23
- 24.
- 25. Why a New Version? OAuth 1.0 was largely based on two exisAng proprietary protocols: Flickr’s API Auth and Google’s AuthSub. The result represented the best soluAon based on actual implementaAon experience. With over 3 years of experience working with the protocol, the community learned enough to rethink and improve the protocol in three main areas where OAuth 1.0 proved limited or confusing 25
- 26. Authen=ca=on and Signatures The majority of failed OAuth 1.0 implementaAon aIempts are caused by the complexity of the cryptographic requirements of the specificaAon. OAuth 1.0 is sAll not trivial to use on the client side. For example, with the move to OAuth, developers are now forced to find, install, and configure libraries in order to accomplish what was before possible with a single line of cURL script. User Experience and Alterna=ve Token Issuance Op=ons OAuth includes two main parts: obtaining a token by asking the user to grant access, and using tokens to access protected resources. The methods for obtaining an access token are called flows. OAuth 1.0 started out with 3 flows: web-‐based applicaAons, desktop clients, and mobile or limited devices. However, as the specificaAon evolved, the three flows were merged into one which (on paper) enabled all three client types. In pracAce, the flow works fine for web-‐based applicaAons but provides an inferior experience elsewhere. Performance at Scale As large providers started using OAuth, the community realized that the protocol does not scale well. It requires state management across different steps, temporary credenAals which are more oZen than not discarded unused, and typically requires issuing long lasAng credenAals which are less secure and harder to manage (and synchronize across data centers). In addiAon, OAuth 1.0 requires that the protected resources endpoints have access 26
- 27. Flows NaAve applicaAon support (applicaAons running on a desktop or mobile device) can be implemented using many of the flows above. Bearer tokens OAuth 2.0 provides a cryptography-‐free opAon for authenAcaAon which is based on exisAng cookie authenAcaAon architecture. Instead of sending signed requests using HMAC and token secrets, the token itself is used as a secret sent over HTTPS. This allows making API calls using cURL and other simple scripAng tools without having to canonicalize the request and sign it. Simplified signatures Signature support has been significantly simplified to remove the need for special parsing, encoding, and sorAng of parameters. It also uses a single secret instead of two. Short-‐lived tokens with Long-‐lived authoriza=ons Instead of issuing a long lasAng token (typically good for a year or unlimited lifeAme), the server can issues a short-‐lived access token and a long lived refresh token. This allows clients to obtain a new access token without having to involve the user again, but keeps access tokens limited. Separa=on of Roles OAuth 2.0 separates the role of the authorizaAon server responsible for obtaining user authorizaAon and issuing tokens from that of the resource server handling API 27
- 28. In July 2012, Eran Hammer resigned his role of lead author for the OAuth 2.0 project, withdrew from the IETF working group, and removed his name from the specificaAon. Hammer pointed to a conflict between the web and enterprise cultures, ciAng the IETF as a community that is "all about enterprise use cases", that is "not capable of simple." What is now offered is a blueprint for an authorizaAon protocol, he says, and "that is the enterprise way", providing a "whole new fronAer to sell consulAng services and integraAon soluAons.” Despite this, it has been noted that OAuth 2.0 doesn't fit enterprise cultures either. Management is unlikely to want to offer an external API upon a framework which is non-‐interoperable and presents unquanAfiable risk. In comparing OAuth 2.0 with 1.0, Hammer points out that it has become "more complex, less interoperable, less useful, more incomplete, and most importantly, less secure." 28
- 29.
- 30. OAuth2 is more infrastructure than protocol 6 New Flows in Oauth 2.0 User-‐Agent Flow – for clients running inside a user-‐agent (typically a web browser). Web Server Flow – for clients that are part of a web server applicaAon, accessible via HTTP requests. This is a simpler version of the flow provided by OAuth 1.0. Device Flow – suitable for clients execuAng on limited devices, but where the end-‐ user has separate access to a browser on another computer or device. Username and Password Flow – used in cases where the user trusts the client to handle its credenAals but it is sAll undesirable for the client to store the user’s username and password. This flow is only suitable when there is a high degree of trust between the user and the client. Client Creden=als Flow – the client uses its credenAals to obtain an access token. This flow supports what is known as the 2-‐legged scenario. Asser=on Flow – the client presents an asserAon such as a SAML asserAon to the authorizaAon server in exchange for an access token. 30
- 31. The AuthorizaAon Code or Web server flow is suitable for clients that can interact with the end-‐user’s user-‐agent (typically a Web browser), and that can receive incoming requests from the authorizaAon server (can act as an HTTP server). The AuthorizaAon Code flow is as follows: 1. The Web server redirects the user to the API Gateway acAng as an AuthorizaAon Server to authenAcate and authorize the server to access data on their behalf. 2. AZer the user approves access, the Web server receives a callback with an authorizaAon code. 3. AZer obtaining the authorizaAon code, the Web server passes back the authorizaAon code to obtain an access token response. 4. AZer validaAng the authorizaAon code, the API Gateway passes back a token response to the Web server. 5. AZer the token is granted, the Web server accesses their data. hIp://docs.oracle.com/cd/E39820_01/doc.11121/gateway_docs/content/ oauth_flows.html 31
- 32. hIps://developers.google.com/accounts/docs/OAuth2WebServer 1. Scope -‐ IdenAfies the Google API access that your applicaAon is requesAng. Redirect_uri -‐ Determines where the response is sent. Client_id -‐ IdenAfies the client that is making the request. State – sender specific applicaAon state Response_type = code -‐ Determines whether the Google OAuth 2.0 endpoint returns an authorizaAon code approval_prompt -‐ Indicates whether the user should be re-‐prompted for consent. Default is auto. -‐-‐-‐ 3. Code -‐ The authorizaAon code returned from the iniAal request. 32
- 33. 4. client_secret -‐ The client secret obtained from the Developers Console. 5. access_token The token that can be sent to a Google API. refresh_token A token that may be used to obtain a new access token. Refresh tokens are valid unAl the user revokes access. This field is only present if access_type=offline is included in the authorizaAon code request. expires_in The remaining lifeAme of the access token. token_type IdenAfies the type of token returned. At this Ame, this field will always have the value Bearer. 33
- 34. The Implicit Grant (User-‐Agent) authenAcaAon flow is used by client applicaAons (consumers) residing in the user's device. This could be implemented in a browser using a scripAng language such as JavaScript, or from a mobile device or a desktop applicaAon. These consumers cannot keep the client secret confidenAal (applicaAon password or private key). The User Agent flow is as follows: 1. The Web server redirects the user to the API Gateway acAng as an AuthorizaAon Server to authenAcate and authorize the server to access data on their behalf. 2. AZer the user approves access, the Web server receives a callback with an access token in the fragment of the redirect URL. 3. AZer the token is granted, the applicaAon can access the protected data with the access token. 35
- 35. The Resource Owner password credenAals flow is also known as the username-‐ password authenAcaAon flow. This flow can be used as a replacement for an exisAng login when the consumer already has the user’s credenAals. The Resource Owner password credenAals grant type is suitable in cases where the Resource Owner has a trust relaAonship with the client (for example, the device operaAng system or a highly privileged applicaAon). The AuthorizaAon Server should take special care when enabling this grant type, and only allow it when other flows are not viable. This grant type is suitable for clients capable of obtaining the Resource Owner's credenAals (username and password, typically using an interacAve form). It is also used to migrate exisAng clients using direct authenAcaAon schemes such as HTTP Basic or Digest authenAcaAon to OAuth by converAng the stored credenAals to an access token. 36
- 36. The client credenAals grant type must only be used by confidenAal clients. The client can request an access token using only its client credenAals (or other supported means of authenAcaAon) when the client is requesAng access to the protected resources under its control. The client can also request access to those of another Resource Owner that has been previously arranged with the AuthorizaAon Server (the method of which is beyond the scope of the specificaAon). 37
- 37. A JSON Web Token (JWT) is a JSON-‐based security token encoding that enables idenAty and security informaAon to be shared across security domains. In the OAuth 2.0 JWT flow, the client applicaAon is assumed to be a confidenAal client that can store the client applicaAon’s private key. The X.509 cerAficate that matches the client’s private key must be registered in the API Manager. The API Gateway uses this cerAficate to verify the signature of the JWT claim. 38
- 38. Part of infrastructure! You do not need to create its own API! In some cases a user may wish to revoke access given to an applicaAon. An access token can be revoked by calling the API Gateway revoke service and providing the access token to be revoked. A revoke token request causes the removal of the client permissions associated with the parAcular token to access the end-‐user's protected resources. POST /api/oauth/revoke HTTP/1.1 AuthorizaAon: Basic U2FtcGxlQ29uZmlkZW50aW… You can use the Token Info Service to validate that an access token issued by the API Gateway. A request to the tokenInfo service is an HTTP GET request for informaAon in a specified OAuth 2.0 access token. GET /api/oauth/tokeninfo HTTP/1.1 access_token=4eclEUX1N6oVIOoZBbaDTI977S… 39
- 39. OAuth is oZen called “protocol for robots," in contrast to OpenID -‐ « protocol for users." Do not confuse them ! OpenID -‐ protocol for accelerated registra=on. OpenID enables the user to enter a password to get an account on any service, if it is already registered somewhere else on the Internet. ( And then you can not enter a password to log on to the service being authorized "somewhere ." ) For example, if you have an account on Yandex , you can " go " with it on any service that supports OpenID-‐ authorizaAon. OAuth -‐ protocol for authorized access to third-‐party API. OAuth allows the script to get a Consumer-‐ limited API-‐ party access to the data Service Provider-‐ and if User gives good. Ie a means for access to the API. 41
- 40. Милицейская аналогия: Представьте, что вы — сотрудник Уголовного розыска, ищущий концы в деле о краже WebMoney за 1973-‐й год. Договоримся о терминах: OAuth Consumer: Уголовный розыск. User: сотрудник Уголовного розыска. Service Provider: Картотека архива преступлений. OpenID методика: сотрудник Уголовного розыска (User) приходит в Картотеку (Service Provider), предъявляет на входе ксиву (AuthorizaAon) и на месте перебирает карточки в поисках информации. Oauth методика: сотрудник Уголовного розыска (User) прямо с работы (Consumer) звонит в Картотеку (Service Provider). Он докладывает свою фамилию; если его узнают (AuthorizaAon), он просит предоставить список всех преступлений за 1973-‐й год (API call). Как видите, OpenID и OAuth — разные вещи. OpenID позволяет вам прямо на месте получить доступ к некоторым ресурсам. OAuth обеспечивает получение части информации с удаленного сервиса через API. 42
- 41. What is OpenID Connect? OpenID Connect 1.0 is a simple idenAty layer on top of the OAuth 2.0 protocol. It allows Clients to verify the idenAty of the End-‐User based on the authenAcaAon performed by an AuthorizaAon Server, as well as to obtain basic profile informaAon about the End-‐User in an interoperable and REST-‐like manner. 43
- 42. How is OpenID Connect different than OpenID 2.0? OpenID Connect performs many of the same tasks as OpenID 2.0, but does so in a way that is API-‐friendly, and usable by naAve and mobile applicaAons. OpenID Connect defines opAonal mechanisms for robust signing and encrypAon. Whereas integraAon of OAuth 1.0a and OpenID 2.0 required an extension, in OpenID Connect, OAuth 2.0 capabili=es are integrated with the protocol itself. 44
- 43.
- 44.
- 45. More Oauth 2.0 Flows to allow beIer support for non-‐browser based applicaAons. OAuth 2.0 no longer requires client applicaAons to have cryptography. This hearkens back to the old TwiIer Auth API, which didn't require the applicaAon to HMAC hash tokens and request strings. With OAuth 2.0, the applicaAon can make a request using only the issued token over HTTPS. OAuth 2.0 signatures are much less complicated. No more special parsing, sorAng, or encoding. OAuth 2.0 Access tokens are "short-‐lived". Typically, OAuth 1.0 Access tokens could be stored for a year or more (TwiIer never let them expire). OAuth 2.0 has the noAon of refresh tokens. Finally, OAuth 2.0 is meant to have a clean separaAon of roles between the server responsible for handling OAuth requests and the server handling user authorizaAon. 47
- 46.
- 47.
- 48.