koenbuyens / vulnerable-oauth-2.0-applications Goto Github PK

vulnerable OAuth 2.0 applications: understand the security implications of your OAuth 2.0 decisions.

JavaScript 67.22% HTML 14.85% CSS 17.55% Dockerfile 0.38%

oauth security jwt-token refresh-token authorization-code-grant password-grant resource-owner-grant client-credentials

vulnerable-oauth-2.0-applications's Introduction

OAuth 2.0: Security Considerations

TL;DR

We show how to use OAuth 2.0 securely when using a Classic Web Application, a Single Page Application, and a Mobile Application as clients. For each of these clients, we elaborate on the overall design, implement that design, and touch upon common security mistakes. You can exploit these mistakes by deploying the damn vulnerable OAuth 2.0 applications.

OAuth 2.0: Security Considerations

Introduction

In this article, we elaborate on common security mistakes that architects and developers make when designing or implementing OAuth 2.0-enabled applications. The article not only describes these mistakes from a theoretical perspective, but also provides a set of working sample applications that contain those mistakes. This serves three purposes:

developers are able to identify a missing security control and learn how to implement it securely.
architects and developers are able to assess the impact of not implementing a security control.
Testers are able to identify the mistakes in a running application.

The article is structured as follows. Section Background introduces the OAuth 2.0 Protocol using a running example. The subsequent sections show how to use OAuth 2.0 when using a Classic Web Application, a Single Page Application, and Mobile Application as clients. For each of these sections, we elaborate on the overall design, implement that design using the MEAN stack, and touch upon common security mistakes. Section Checklists summarizes this article in the form of checklists for architects, developers, and testers. Finally, Section Conclusion concludes.

Note: the mistakes are common across technology stacks; we use the MEAN stack for illustration purposes only.

Running Example and Background

Our canonical running example consists of a web site that enables users to manage pictures, named gallery. This gallery application is similar to flickr.com in the sense that users can upload pictures, share them with friends, and organize those pictures in different albums.

As our gallery application became quite popular, we got requests from various companies to integrate with our gallery application. To that end, we decided to open up the REST API that forms the foundation of our application towards those companies. These companies use the following types of clients:

a third-party website that allows users to print the pictures hosted at our gallery site, named photoprint.
a third-party mobile application that enables users to upload pictures, named mypics.
a first-party mobile application that enables gallery users to upload pictures and change their profile, named mobilegallery.
a single-page application displaying a live feed of a posted pictures, named livepics.

As we are concerned about security, users should be able to give those third-party applications permission to access their pictures without providing their username and password to those applications. It seems that the OAuth 2.0 protocol might help achieve our goals.

OAuth 2.0 is a standard that enables users to give websites access to their data/services at other websites. For instance, a user gives a photo printing website access to her pictures on Flickr. Before performing a deep-dive into the specifics of OAuth 2.0, we introduce some definitions (taken from auth0):

Resource Owner: the entity that can grant access to a protected resource. Typically this is the end-user.
Client: an application requesting access to a protected resource on behalf of the Resource Owner. This is also called a Relying Party.
Resource Server: the server hosting the protected resources. This is the API you want to access, in our case gallery.
Authorization Server: the server that authenticates the Resource Owner, and issues access tokens after getting proper authorization. This is also called an identity provider (IdP).
User Agent: the agent used by the Resource Owner to interact with the Client, for example a browser or a mobile application.

In OAuth 2.0, the interactions between the user and her browser, the Authorization Server, and the Resource Server can be performed in four different flows.

the authorization code grant: the Client redirects the user (Resource Owner) to an Authorization Server to ask the user whether the Client can access her Resources. After the user confirms, the Client obtains an Authorization Code that the Client can exchange for an Access Token. This Access Token enables the Client to access the Resources of the Resource Owner.
the implicit grant is a simplification of the authorization code grant. The Client obtains the Access Token directly rather than being issued an Authorization Code.
the resource owner password credentials grant enables the Client to obtain an Access Token by using the username and password of the Resource Owner.
the client credentials grant enables the Client to obtain an Access Token by using its own credentials.

Do not worry if you do not understand the flows right away. They are elaborated upon in detail in subsequent sections. What you should remember is that:

Clients can obtain Access Tokens via four different flows.
Clients use these access tokens to access an API.

An OAuth 2.0 Enabled Application: Architecture, Design, Implementation, and Testing: Common Mistakes

You make many design decisions when architecting an OAuth 2.0 enabled application. Read Architect: Major Design Decisions to understand the security impact of major design decisions, such as the selected OAuth 2.0 grant, the use of refresh tokens, and integrating with third parties.

Once you selected the grants, you need to make various local design decisions as well as implementation decisions.

Read Authorization Code Grant to understand how to use this grant for a classic web application.
- Read Developer: Minor Design Decisions and Insecure Implementation to understand the common security pitfals and how to avoid them.
- Read Tester: Exploit Mistakes to understand how you can detect and exploit those common mistakes.
Read Implicit Grant to understand how to use this grant for a Single-Page web application.
Read Resource Owner Password Credentials Grant to understand how to use this flow with a first party mobile application.
Read Client Credentials Grant to understand how to use this flow in a B2B scenario.
Read Authorization Code Grant with PKCE to understand how to use this grant for a third-party mobile application.

Conclusion

In this article, we showed how to use OAuth 2.0 securely when using

a Classic Web Application,
a Single Page Application, and
a Mobile Application as clients. For each of these clients, we elaborated on the overall design, implemented that design using the MEAN stack, and touched upon common security mistakes.

References

Partially taken from https://oauth.net/2/.

OAuth 2.0 Core

Mobile and Other Devices

Token and Token Management

Other Extensions

Community Resources

Protocols Built on OAuth 2.0

TODOs

Photoprint: implement obtaining a profile, authenticating, and storing orders (to illustrate OpenId connect).
Gallery: refresh token, support for other grants.
Classic Web App: remaining security considerations.
Mobile Application: all
SPA: all

vulnerable-oauth-2.0-applications's People

Contributors

Stargazers

Watchers

Forkers

security-prince incredibleindishell ntgitdude23 droidzzzio dimpol rusakovichma w1tch3rr bbhunter m8r1us hunter0x8 superdeen pravinkumarosingh sri222149 kp-forks ashis101 5l1v3r1 th3cyb3rc0p ravipraj attacker-codeninja 0xlyk4n hackerup sagarchhatrala thisedgarmarquez malys rockcena spiritedwolf adriendb sec642 dleyanlin f13-cybertech fbarre96 vincss-pentest bhishma14 doanhnhq-uit tree-chtsec rajesh457 rudsarkar sachinpatkar cybernewbies egbobright cybersimple nejibnbm cyb3rd0g-cell 0xagun rafay74 aussinfosec recepkizilarslan adamnaoui davidfraval khizarkhanhoti dinosn 0xsojalsec bbhunty amon22 qemm d0ct0r-inf0s3c hessandrew tinkerermaruthu insi2304 mohanmvasista hoppersploit tuffacton abd-4fg vulnerable-code grandbudha r0075h3ll mwebsec jasongreige bassmatt

vulnerable-oauth-2.0-applications's Issues

MongoDb crashing

If you get the following error and MongoDb crashes:
Error parsing command line: unrecognized option '--smartfiles' simply change the image tag on docker-compose.yml:

image: mongo:4.0

problem in gallery install

Error: Cannot find module 'express-session'
Require stack:

/home/kali/lab/Vulnerable-OAuth-2.0-Applications/insecureapplication/gallery/app.js
at Module._resolveFilename (node:internal/modules/cjs/loader:1134:15)
at Module._load (node:internal/modules/cjs/loader:975:27)
at Module.require (node:internal/modules/cjs/loader:1225:19)
at require (node:internal/modules/helpers:177:18)
at Object. (/home/kali/lab/Vulnerable-OAuth-2.0-Applications/insecureapplication/gallery/app.js:4:24)
at Module._compile (node:internal/modules/cjs/loader:1356:14)
at Module._extensions..js (node:internal/modules/cjs/loader:1414:10)
at Module.load (node:internal/modules/cjs/loader:1197:32)
at Module._load (node:internal/modules/cjs/loader:1013:12)
at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:128:12) {
code: 'MODULE_NOT_FOUND',
requireStack: [
'/home/kali/lab/Vulnerable-OAuth-2.0-Applications/insecureapplication/gallery/app.js'
]
}

Node.js v18.19.0

WAPTX v2 elearnsecruity

Do you know elearnsecurity which is now ine.com use this repo as a learning material???

0auth

docker-compose.yml parsing issue

docker-compose up
ERROR: yaml.scanner.ScannerError: mapping values are not allowed here
in "./docker-compose.yml", line 33, column 70

Getting this error when running docker-compose up using docker-compose.yml

if anybody have problem with database or register a user solution

when i to registered a user in galley i got follwing error : undefine value name

solution

go in model open user.js and set name:{require:false}

and go in mongodb and remove name field by typing command

db.users.dropIndex("name_1")

Why does replaying auth code gives access to resources

I believe Auth code grant flow is in use in the photoprint/gallery web application demo. I am sending response type=code in the request and in response , I am getting auth code, if I use this to access resources without providing client id+secret , am able to get access to resource pcitures .
Am I missing something here or is it a flaw there ?

Error with mongoseed

Hi,
I have a problem with mongo db.
Here my result when i launch docker-compose up :

% docker-compose up Recreating mongodb ... done Starting insecureapplication_selenium_1 ... done Recreating mongoseed ... done Recreating gallery ... done Recreating photoprint ... done Recreating attacker ... done Attaching to mongodb, insecureapplication_selenium_1, mongoseed, gallery, photoprint, attacker gallery | gallery | > [email protected] start /usr/src/app gallery | > node app.js gallery | selenium_1 | 2022-10-31 18:23:42,553 INFO Included extra file "/etc/supervisor/conf.d/selenium-debug.conf" during parsing selenium_1 | 2022-10-31 18:23:42,559 INFO Included extra file "/etc/supervisor/conf.d/selenium.conf" during parsing selenium_1 | 2022-10-31 18:23:42,563 INFO supervisord started with pid 7 selenium_1 | 2022-10-31 18:23:43,573 INFO spawned: 'xvfb' with pid 9 selenium_1 | 2022-10-31 18:23:43,576 INFO spawned: 'fluxbox' with pid 10 selenium_1 | 2022-10-31 18:23:43,615 INFO spawned: 'vnc' with pid 11 selenium_1 | 2022-10-31 18:23:43,716 INFO spawned: 'selenium-standalone' with pid 13 selenium_1 | 2022-10-31 18:23:44,125 INFO success: xvfb entered RUNNING state, process has stayed up for > than 0 seconds (startsecs) selenium_1 | 2022-10-31 18:23:44,125 INFO success: fluxbox entered RUNNING state, process has stayed up for > than 0 seconds (startsecs) selenium_1 | 2022-10-31 18:23:44,125 INFO success: vnc entered RUNNING state, process has stayed up for > than 0 seconds (startsecs) selenium_1 | 2022-10-31 18:23:44,126 INFO success: selenium-standalone entered RUNNING state, process has stayed up for > than 0 seconds (startsecs) selenium_1 | 18:23:45.760 INFO [GridLauncherV3.parse] - Selenium server version: 3.141.59, revision: e82be7d358 selenium_1 | 18:23:46.342 INFO [GridLauncherV3.lambda$buildLaunchers$3] - Launching a standalone Selenium Server on port 4444 selenium_1 | 2022-10-31 18:23:46.578:INFO::main: Logging initialized @2624ms to org.seleniumhq.jetty9.util.log.StdErrLog mongodb | mongodb | WARNING: MongoDB 5.0+ requires a CPU with AVX support, and your current system does not appear to have that! mongodb | see https://jira.mongodb.org/browse/SERVER-54407 mongodb | see also https://www.mongodb.com/community/forums/t/mongodb-5-0-cpu-intel-g4650-compatibility/116610/2 mongodb | see also https://github.com/docker-library/mongo/issues/485#issuecomment-891991814 mongodb | mongodb exited with code 132 mongoseed | mongoseed | WARNING: MongoDB 5.0+ requires a CPU with AVX support, and your current system does not appear to have that! mongoseed | see https://jira.mongodb.org/browse/SERVER-54407 mongoseed | see also https://www.mongodb.com/community/forums/t/mongodb-5-0-cpu-intel-g4650-compatibility/116610/2 mongoseed | see also https://github.com/docker-library/mongo/issues/485#issuecomment-891991814 mongoseed | photoprint | photoprint | > [email protected] start /usr/src/app photoprint | > node app.js photoprint | photoprint | Printing Application listening on http://localhost:3000 attacker | attacker | > [email protected] start /usr/src/app attacker | > node app.js attacker | selenium_1 | 18:23:47.797 INFO [WebDriverServlet.<init>] - Initialising WebDriverServlet gallery | Gallery Application listening on :::3005 gallery | (node:17) UnhandledPromiseRejectionWarning: MongoNetworkError: failed to connect to server [mongodb:27017] on first connect [MongoNetworkError: getaddrinfo EAI_AGAIN mongodb:27017] gallery | at Pool.<anonymous> (/usr/src/app/node_modules/mongodb-core/lib/topologies/server.js:564:11) gallery | at emitOne (events.js:116:13) gallery | at Pool.emit (events.js:211:7) gallery | at Connection.<anonymous> (/usr/src/app/node_modules/mongodb-core/lib/connection/pool.js:317:12) gallery | at Object.onceWrapper (events.js:317:30) gallery | at emitTwo (events.js:126:13) gallery | at Connection.emit (events.js:214:7) gallery | at Socket.<anonymous> (/usr/src/app/node_modules/mongodb-core/lib/connection/connection.js:246:50) gallery | at Object.onceWrapper (events.js:315:30) gallery | at emitOne (events.js:116:13) gallery | at Socket.emit (events.js:211:7) gallery | at emitErrorNT (internal/streams/destroy.js:73:8) gallery | at _combinedTickCallback (internal/process/next_tick.js:139:11) gallery | at process._tickCallback (internal/process/next_tick.js:181:9) gallery | (node:17) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1) gallery | (node:17) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code. selenium_1 | 18:23:48.093 INFO [SeleniumServer.boot] - Selenium Server is up and running on port 4444 attacker | Attacker Application listening on :::1337 mongoseed | 2022-10-31T18:24:12.950+0000 error connecting to host: could not connect to server: server selection error: server selection timeout, current topology: { Type: Single, Servers: [{ Addr: mongodb:27017, Type: Unknown, Last error: connection() error occurred during connection handshake: dial tcp: lookup mongodb: Temporary failure in name resolution }, ] } mongoseed exited with code 1

insecureapplication/gallery/package.json references a non-existent package as its dependency

  "dependencies": {
    "amdefine": "^1.0.1",
    "array-set": "^0.1.2",
    "connect-ensure-login": "^0.1.1",
    "cookie-parser": "^1.4.3",
    "errorhandler": "^1.5.0",
    "express": "^4.16.3",
    "express-session": "^1.15.6",
    "helmet": "^3.13.0",
    "jade": "^1.11.0",
    "mongoose": "^5.2.14",
    "morgan": "^1.9.1",
    "multer": "^1.3.1",
    "oauth2orize": "^1.11.0",
    "passport": "^0.4.0",
    "passport-http": "^0.3.0",
    "passport-http-bearer": "^1.0.1",
    "passport-local-mongoose": "^5.0.1",
    "passport-oauth2-client-password": "^0.1.2",
    "pug": "^2.0.3"
  }

package.json file in Vulnerable-OAuth-2.0-Applications/insecureapplication/gallery declares a package - array-set - as one of its dependecies. Though, the installation is aborted after the following error is thrown

4.751 npm ERR! code E404
4.754 npm ERR! 404 Not Found - GET https://registry.npmjs.org/array-set/-/array-set-0.1.2.tgz
4.754 npm ERR! 404
4.754 npm ERR! 404  '[email protected]' is not in the npm registry.
4.755 npm ERR! 404 You should bug the author to publish it (or use the name yourself!)
4.756 npm ERR! 404 It was specified as a dependency of 'app'
4.756 npm ERR! 404
4.756 npm ERR! 404 Note that you can also install from a
4.757 npm ERR! 404 tarball, folder, http url, or git url.

Upon searching manually, and doing an npm search array-set, it was found out that the package, with the name array-set, doesn't exist anymore which breaks the installation.