DEV Community: Antoine Carossio

[Webinar] How to secure GraphQL

Antoine Carossio — Fri, 12 Apr 2024 13:06:53 +0000

Join Uri Goldshtein, founder of the Guild, and Tristan Kalos, CEO and co-founder at Escape, for a webinar on the challenges of GraphQL security.

Both Tristan and Uri are GraphQL security experts and active contributors to GraphQL Armor.

During this live discussion, they will explore the critical aspects of securing GraphQL APIs, addressing common vulnerabilities, sharing their experiences and discussing best practices for ensuring strong security measures. Additionally, Uri and Tristan will share their insights into emerging threats in the GraphQL ecosystem and strategies for mitigating them effectively.

Our goal is to make this webinar highly engaging, so don't be shy! Come and ask your questions via chat! 😉

Can't make it? No worries, we'll share the replay afterward.

How to secure your API secret keys from being exposed?

Antoine Carossio — Fri, 15 Mar 2024 11:34:11 +0000

The uncontrolled sprawl of exposed, insecure APIs puts sensitive personal and corporate data at high risk, as shown by the numerous data breaches like the T-Mobile hack ($350M fine in 2022), the Peloton data exposure in 2021, and many others.

However, in some cases, instead of the API itself being insecure, the main reason for the breaches is the leaking of API secret keys and tokens. The 2023 incidents, including the leaked Microsoft Account Consumer Key and the OpenSea third-party vendor breach, perfectly illustrate how secrets can be exploited in attacks.

The exposure of API secret keys, which authenticate and authorize requests to your API, to outsiders can jeopardize the security and privacy of your application and have a substantial financial impact - think $17M we discovered via one exposed Stripe token. For more information, check out our report "The API Secret Sprawl" and learn how we discovered over 18,000 API secret tokens and $20M in Stripe tokens.

In this blog post, I dive into the nature of API secret keys and the risks associated with their exposure. More than that, I’ll share essential practices for securing your API secret keys against leaks in front ends - when it's too late. Adopting these strategies will help you protect your applications - which is a continuous journey anyway!

What are secret API keys?

Secret API keys are unique identifiers used by applications to authenticate and authorize access to an API. They serve as a form of authentication, allowing the API to verify the identity of the requesting application. These keys are typically kept confidential and should be securely managed to prevent unauthorized access to sensitive data or actions within the API.

Secret API keys serve as secure tokens to authenticate and authorize requests made to your API. They are deemed secret because their exposure to unauthorized individuals or the public could lead to security breaches. If a malicious entity gains access to your secret API key, they could potentially impersonate you, gaining the ability to access or alter your data, functionality, and resources.

What's the difference with the regular API keys you might ask yourself?

These secret keys are distinct from regular API keys, which primarily serve to identify you to the API. Unlike regular keys that are often transmitted in an unencrypted manner, such as within a URL’s query string or in the headers of a request, secret API keys encrypt your requests. These encrypted requests are then decrypted by the server using the matching secret key, ensuring that the request is indeed originating from you.

Moreover, some APIs opt for a dual-key security mechanism, incorporating a pair of keys like an API key and an App ID, or an API key and a secret. In such scenarios, both keys must be submitted with requests. However, only one is exploited for encryption purposes, while the other assists the server in retrieving the corresponding secret key for decryption. This dual-key approach fortifies security by enabling the server to verify both the requester’s identity and the request’s authenticity.

What causes API key exposure?

API key exposure is a grave security concern that arises from several practices. Identify and avoid the following common causes to protect your API keys:

Embedding API keys in code (please, don't 🙏): This dangerous practice can unintentionally reveal your API keys to the public, especially if your code is shared on platforms like GitHub. If your code is accessible, so are your API keys, making them vulnerable to misuse by malicious actors.
Storing API keys in your application's source tree: Another hazardous approach is to store your API keys within your application’s source files. Such a practice makes your API keys vulnerable to being leaked if your source code control system is compromised or if it's publicly accessible.
Storying API keys in front-end code like Javascript: in our research 35% of the exposed secrets were found in a JavaScript file. Some developers opt to compile all code, including sensitive setup files, into a single extensive JavaScript file for convenience. However, this approach unwittingly exposes crucial secrets to unauthorized access, which is critical for the seamless operation and intercommunication of the application.
Sending API keys in plain text: A frequent oversight is transmitting API keys without encryption, leaving them exposed to anyone who might intercept your network traffic - this includes hackers, internet service providers, or government entities. To prevent this, always encrypt your API keys and use secure communication protocols like HTTPS when interacting with your API server.
Using the same API keys for multiple APIs or services: Employing the same API key across different services not only indicates poor design but also magnifies the consequences of a single API key exposure. An exposed key could jeopardize multiple services or APIs. Maintain separate API keys for each service and limit their use to necessary scopes and domains.

Steering clear of these common pitfalls can significantly lower the risk of your API keys becoming exposed, thus ensuring the security, privacy, and efficiency of your application.

Best practices to secure your API secret keys

Here are the essential steps to mitigate the risks of secret API keys exposure:

Centralize API keys and tokens management: Centralizing token management enables secure storage, access, and rotation. Consolidating all tokens in one location allows you to monitor their usage comprehensively, identifying potential vulnerabilities in your system.
Rotate API keys and tokens Regularly: Regularly rotating tokens mitigates the risk in case of compromise. For instance, AWS Secrets Manager supports the automated rotation of secrets.
Assign Tokens to Specific Teams or Services: Ensure that only necessary personnel or services have access to each token by assigning them to specific teams or services.
Create a Revocation Process: Establish a clear revocation process to promptly revoke tokens in the event of a compromise.
Grant Correct Permissions: Grant only the necessary permissions for each token to minimize potential damage.
Limit Token Scope: Restrict the access scope of each token within your system.
Monitor Usage Patterns: Keep a vigilant eye on how tokens are used to identify any unusual activity.
Educate Your Internal Teams: Ensure that all team members understand the importance of token security and adhere to best practices. Consider enhancing the security experience through gamification or implementing a Security Champion Program, following The Security Champion Program Success Guide.

These measures are crucial for protecting your API tokens and maintaining secure and compliant systems. For more detailed information, you can refer to the resources provided by AWS Secrets Manager and Hashicorp.

Don't wait until it’s too late! Begin implementing these security measures as quickly as possible.

Workshop - How to Write Custom Security Tests

Antoine Carossio — Fri, 15 Mar 2024 11:25:46 +0000

Custom rules help you test the custom business logic of your applications and gain full control of your API security posture.

Don't know why you need custom security tests and where to start? We'll be organizing a workshop on this topic

The goal is to guide you through advanced techniques and offer practical insights to improve your security protocols.

You'll learn:

The importance of custom security tests and how to write them
Setting up rules for various API vulnerabilities
Creating rules based on bug bounty or pentesting reports
Fine-tuning Escape rules to catch issues specific to your APIs
Ensuring your rules adapt to each API update and newly discovered APIs
By the end of this workshop, you'll have a clear path to establish a robust API security posture for your organization's APIs.

📅 When? 11:00 a.m. EST on Thursday, March 21st.

Can't make it? You can still sign up, and you'll receive a session recording once it ends.

Methodology: How we discovered over 18,000 API secret tokens

Antoine Carossio — Wed, 24 Jan 2024 16:40:36 +0000

Hey there!

It's just the beginning of the year, but our security research team has been working hard to identify current API security challenges.

So for the Escape team, January went under the tagline "API secret sprawl" (we thought it was more fun than"Dry January", and we hope you agree with us 😉).

If you're in the security field, you might mention that the beginning of the year usually marks the release of all "State of.. " reports, taking a look at the past year's trends. Instead of collecting opinions or our tool data, we decided to look at the real world. That's how the whole project started, and we were shocked at what it led to.

Our security research team scanned 189.5M URLs and found more than 18,000 exposed API secrets. 41% of exposed secrets were highly critical, i.e. could lead to significant financial risks for the organizations, as exposed financial tokens and API keys included $20 million in vulnerable Stripe tokens.

Unlike other reports, Escape’s web crawler analyzed applications in their actual usage scenarios, examining everything from APIs to frontends, including elements that run in the background, like JavaScript. This approach shows how and where API secret keys and tokens are exposed in real-world settings, not only in code repositories.

You can review the complete results in our comprehensive report. Meanwhile, in this article, we'll show you the methodology that guided us to these impressive findings.

Methodology

Development of the web spider

To tackle the complex task of scanning 1 million domains, we developed a specialized web spider. This tool was built using Golang, chosen for its excellent input/output (I/O) throughput, good productivity, and strong support for concurrency. These features of Golang were crucial for efficiently processing large volumes of web data.

For networking, we relied on a library named fasthttp (fasthttp GitHub), known for its high performance. fasthttp was instrumental in enabling our spider to handle numerous network requests swiftly and effectively.

To interpret and analyze JavaScript found on web pages, we used tree-sitter (Tree-sitter), a parser generator tool and an incremental parsing library.

It helped us build a robust mechanism to understand and process JavaScript code, which is a critical component in modern web applications.

The Golang-based spider was containerized and designed to listen on a Kafka (Redpanda) stream. This setup allowed for scalable and efficient handling of data streams.

In terms of secret analysis, we incorporated an existing Python-based service that we regularly use at Escape. This tool, which employs natural language processing, was accessed via gRPC.

The whole solution was deployed on a Kubernetes cluster, leveraging the orchestration.

Data gathering strategy

For our comprehensive analysis, we chose to examine the 1 million most popular domains.

The list of these domains was sourced from the Majestic Million dataset, which ranks websites based on the number of referring subnets. This ranking offered us a diverse set of domains to study, spanning various sectors and sizes.

We acknowledge a potential bias in our approach. Typically, larger domains with more resources might have better security measures, possibly leading to fewer instances of secret sprawl. In contrast, smaller websites or those without dedicated security teams might be more prone to such issues. However, our study focused on the most popular domains without specifically addressing this bias.

Alternatively, with over 365 million domain names reported across the internet, our sample size becomes relatively small, potentially leading to greater volatility in the number of findings.

The data collection was a one-time process, based on the latest available list from the Majestic dataset. During the collection, we encountered several limitations. To respect legal and ethical boundaries, we deliberately excluded certain types of domains. This included governmental, educational, and health-related domains, as regular users are not typically authorized to explore these. This decision ensured that our study adhered to the ethical norms of web crawling and data collection.

By focusing on domains that are accessible to the general public, our study provides insights into the state of secret sprawl in the broader, more publicly engaged segments of the internet. This focus enables a comprehensive evaluation of security practices and the challenges encountered in a diverse array of online platforms and environments. Through this lens, we gain a deeper understanding of how secret sprawl impacts various sectors and what this means for the broader digital security posture.

Data collection process

Our data collection process was a significant undertaking, both in terms of scale and technical complexity. To manage this, we deployed our containerized web spider on a Kubernetes cluster. The cluster was capable of scaling up to 150 concurrent worker instances. This level of scalability was crucial for effectively managing the immense task of scanning 1 million domains, allowing us to distribute the workload efficiently and process a vast amount of data.

The collection spanned over 69 hours, with our system analyzing an average of 4 domains per second. This pace resulted in a total sum duration of approximately 30,686,535 seconds for the entire operation. On average, each domain, including its subdomains, was analyzed in about 32 seconds. This comprehensive approach ensured that we not only looked at the primary domain but also dived into the numerous subdomains associated with each, providing a more complete picture of the web landscape.

In total, our process led us to visit 189,466,870 URLs. This extensive coverage was key to ensuring that our analysis was as thorough and inclusive as possible. By examining such a large number of URLs, we were able to gain deep insights into the current state of secret sprawl across a wide spectrum of the internet.

Also, we started this project by making a new tool as a test. It was impressive how quickly this tool was made – just three days by one engineer. Combining this quick tool development with the project's computing cost of only about $100 shows how, in today's world, we can get big results, build solutions without spending a lot of money or time.

Data cleanup and verification

One of the most challenging aspects of our study was, for sure, the data cleanup and verification process. While we could not verify the tokens ourselves, we made sure each one was classified accurately. A common pattern we noticed is that many tokens have specific prefixes. For instance, Stripe tokens have various prefixes, but we focused particularly on live secret keys, identified by the prefix 'sk_live_'.

To improve the accuracy of our findings, we refined our heuristics to filter out only classified information. This meant paying special attention to high-entropy keys, which often represent proprietary, undocumented tokens or false positives, and filtering them even more from our primary dataset. This approach helped us focus on the most relevant and potentially impactful tokens.

Verification of the tokens was a crucial step, and it was carried out by the token owners themselves. We alerted the owners only when our system was highly confident about the findings. This was a delicate balance to maintain – ensuring the accuracy of our alerts without the ability to test the keys ourselves. We had to be very sure before alerting affected parties to avoid any false alarms.

This cleanup and verification process was an intricate part of our study, requiring a nuanced understanding of token patterns and careful judgment to minimize false positives. Our method aimed to provide reliable and actionable insights to those whose security might have been compromised.

Conclusion

Securing all your APIs is hard. It’s even harder when your keys and tokens get exposed involuntarily in real-world settings - from APIs to frontends. Your organization is now not only prone to data breach risks but also to severe financial implications.

Our study reveals that API secret sprawl extends across a diverse array of websites, industries, and domain types. Even modern tech industries are not exempt. Organizations must respond fast, adopting best practices to secure themselves against potential threats.

Not sure where to start? Centralizing token management, enforcing rotation policies, segmenting access, intensifying security training, and leveraging automated testing tools are essential steps to mitigate these risks. We've compiled the comprehensive list in our report.

Need guidance tailored to your specific needs? Feel free to reach out!

Introducing agentless API discovery & inventory - Congrats to our tech team!

Antoine Carossio — Thu, 16 Nov 2023 13:43:26 +0000

Hello 👋

Very excited to finally reveal our new capabilities at Escape 🚀

After months of hard work from our tech team, we’re finally releasing a possibility for our users to discover and catalog all APIs within their unique business context!

This feature release was led by @nohehf , with the help of @sophieboulaouli and @gauben ! Thank you for all the efforts, your passion, and your dedication 👏

Our customers needed a solution not only to test their APIs but also to tackle the issue of discovering all of them, including Shadow API. Deployed outside of the organization’s API Gateways and proxies, they create blind spots for security teams, which traditional security solutions can’t capture because they require traffic access.

Escape, on the other hand, provides complete visibility of the attack surface by extracting security signals directly from developer tools and merging this data with custom external exposure intelligence. Once APIs are discovered, the data is organized in a structured inventory that categorizes APIs based on business use, data sensitivity, and security risks.

It’s exciting to see how much was shipped within last months!

Want to see how this feature works? Check out our demo

We built GPT Bot focused on API Security

Antoine Carossio — Mon, 13 Nov 2023 14:20:15 +0000

Hey there 👋
Since last week, OpenAI has been letting anyone create their own version of ChatGPT.

We've jumped on the hype train and decided to combine our API security expertise with ChatGPT's artificial intelligence.

So we've built a GPT Bot that assists security engineers with testing and securing APIs.

Here's how it can make your life easier:

1. Instant expert guidance

Need quick advice on how to perform a security assessment for your API? The API Guardian GPT Bot has got you covered! It can provide instant guidance on various security testing methodologies, including OWASP's API Security Top 10, and help you understand the ins and outs of API security.

GraphQL wordlist's recommendation by API Guardian:

GraphQL wordlist's recommendation by ChatGPT:

It doesn't only provide you with a detailed reply but also recommends relevant links to the most useful Github repos.

2. Personalized recommendations

No two APIs are the same, and our GPT Bot understands that. It can analyze your specific use case and provide tailored recommendations for securing your API. Whether you're dealing with authentication, authorization, encryption, or any other aspect of API security, the GPT Bot can provide guidance tailored to your needs.

3. Stay up-to-date

API security is an ever-evolving field, and it can be challenging to keep up with the latest threats and best practices. The GPT Bot constantly updates its knowledge base to ensure that you're always armed with the most current information and strategies to protect your APIs.

4.Don't miss AI-generated API security jokes

We've decided to make our GPT Bot not only helpful but also funny (as far as you can go with AI-generated jokes, though). As a result, after each response, we hope to bring a smile to your face.

Go and test it out here 🚀

If you encounter any issues, want to add your material to the knowledge base, have suggestions for improvement, or simply like to share your experience, please feel free to ping us on Twitter @escapetechHQ

Building your Product Security Roadmap

Antoine Carossio — Fri, 10 Nov 2023 12:26:14 +0000

Whether you're in the first few weeks of your ProdSec journey or building your Product security program for 2024, you might feel lost trying to wrap your head around all the attack surface your org faces and identifying some of the biggest security gaps. We're organizing our first webinar at Escape to help you learn how to deal with these challenges.

You'll learn:

The Essentials: Understand the foundational elements of product security and why they matter.
Risk Assessment: Identify potential vulnerabilities and threats specific to your organization.
Best Practices: Discover tried and tested methods for securing your applications effectively.
Compliance and Governance: Learn how to align your security roadmap with industry standards and regulations.
Incident Response: Prepare for the unexpected with a well-defined plan for handling security incidents.

By the end of this webinar, you'll have a clear path forward to establish a strong security posture for your organization's products!

📆 When? 9:30a.m. PST on Tuesday, the 28th of November.

Can't make it? No worries, sign up, and you'll receive a session recording once it ends.

API Security Checklist

Antoine Carossio — Tue, 31 Oct 2023 10:47:34 +0000

Do you sometimes find it challenging to spot and address API security vulnerabilities effectively? You're not alone! Many security engineers face challenges in improving API security because technology and cyber threats keep changing. This makes ensuring strong API security a complex but vital task.

Our new API security checklist can help! You can use these guidelines to improve your API security posture. Feel free to adapt these guidelines to match your company's specific needs because, let's face it, no two organizations are exactly the same.

Download it here (no need to provide any personal data). Feel free to share with your team 🤩

Using Protobuf with TypeScript

Antoine Carossio — Tue, 26 Sep 2023 09:32:33 +0000

Liquid syntax error: Unknown tag 'endraw'

Open Source API Security Academy

Antoine Carossio — Tue, 12 Sep 2023 15:12:25 +0000

We just launched our new open-source API Security Academy, built by @gauben -> Link to the repo

You can learn how to identify and mitigate security vulnerabilities in GraphQL apps. The website is currently in beta, but we'll be adding new challenges all the time!

We'll soon publish the technical article on how we built it as well.

If you use GraphQL, feel free to help us by staring and contributing 🤩

Input Validation and Sanitization in GraphQL

Antoine Carossio — Thu, 11 May 2023 10:10:32 +0000

Hey Dev.to community!

I have a lot of questions about how to sanitize and validate GraphQL input, so I decided to write a blog post about it with the different techniques :)

👉 Input Validation and Sanitization in GraphQL

Feel free to share yours in the comments ;)

Best,
Antoine

GraphQL errors: the Good, the Bad and the Ugly

Antoine Carossio — Fri, 07 Apr 2023 23:36:12 +0000

Abstract: We, at Escape, have been using GraphQL for our apps for a long time, before many quality tutorials were available. Because we lacked experience, we made design mistakes on many aspects of our GraphQL API. This article reviews the evolution of how we return errors from our API, for consumption by the frontend and other internal services, emphasizing what could be improved on each step.

👉 Read more directly on our blog: https://escape.tech/blog/graphql-errors-the-good-the-bad-and-the-ugly/

Best,
Antoine