Securing APIs with Open Standards provides tips for securing APIs from the Synack Red Team. It discusses using OpenAPI definitions to document APIs, embracing open box testing, and balancing security and adoption through developer relations. It also demonstrates how insecure user input validation can allow access to private data stored in AWS S3 buckets and how Salesforce record IDs can be brute forced to enable unauthorized access if not properly secured. The presentation emphasizes designing APIs with security in mind, adopting standards like OpenAPI, and balancing security testing with developer onboarding.
Content Strategy and Developer Engagement for DevPortalsAxway
Slides from Write the Docs Ottawa Meet Up at Shopify HQ in Canada, June 24, 2019
We’ll walk through 5 scenarios and concrete ways of reaching a developer community for frictionless and increased engagement.
Discover how to build APIs using the Apigee API Services toolkit. Deep dive into Apigee's API Serives solution, API design and management technology including OAuth and security, persistence & caching, Node.js and more.
Demystify Information Security & Threats for Data-Driven Platforms With Cheta...Chetan Khatri
Pragmatic presentation on Penetration testing for Data-Driven Platforms.
Agenda:
- Motivation
- Information Security - Ethics.
- Encryption
- Authentication
- Information Security & Potential threats with Open Source World.
- Find vulnerabilities.
- Checklist before using any Open Source library.
- Vulnerabilities report.
- Penetration Testing for Data-Driven Developments.
OpenAPI v.Next - Events, Alternative Schemas & the Road AheadTed Epstein
-- Presented at KCDC 2018 --
The OpenAPI Specification, already the most widely used REST API description language, is growing fast, and evolving to meet the challenges that come with broad adoption in a dynamic and diverse API ecosystem. In this session, we'll get up to speed with the latest developments in the OpenAPI spec, the tools ecosystem and member community. We'll show highlighted features of last year's major 3.0 release, dive into the new design capabilities currently in progress, and discuss the evolving roadmap for 3.x, 4.x and beyond.
Content Strategy and Developer Engagement for DevPortalsAxway
Slides from Write the Docs Ottawa Meet Up at Shopify HQ in Canada, June 24, 2019
We’ll walk through 5 scenarios and concrete ways of reaching a developer community for frictionless and increased engagement.
Discover how to build APIs using the Apigee API Services toolkit. Deep dive into Apigee's API Serives solution, API design and management technology including OAuth and security, persistence & caching, Node.js and more.
Demystify Information Security & Threats for Data-Driven Platforms With Cheta...Chetan Khatri
Pragmatic presentation on Penetration testing for Data-Driven Platforms.
Agenda:
- Motivation
- Information Security - Ethics.
- Encryption
- Authentication
- Information Security & Potential threats with Open Source World.
- Find vulnerabilities.
- Checklist before using any Open Source library.
- Vulnerabilities report.
- Penetration Testing for Data-Driven Developments.
OpenAPI v.Next - Events, Alternative Schemas & the Road AheadTed Epstein
-- Presented at KCDC 2018 --
The OpenAPI Specification, already the most widely used REST API description language, is growing fast, and evolving to meet the challenges that come with broad adoption in a dynamic and diverse API ecosystem. In this session, we'll get up to speed with the latest developments in the OpenAPI spec, the tools ecosystem and member community. We'll show highlighted features of last year's major 3.0 release, dive into the new design capabilities currently in progress, and discuss the evolving roadmap for 3.x, 4.x and beyond.
Oracle API Platform Cloud Service Best Practices & Lessons Learntluisw19
I did this presentation in Split/Croatia on March 2017 where I shared our experiences and insights when implementing the Oracle API Platform Cloud Service.
API Documentation Workshop tcworld India 2015Tom Johnson
This is a workshop I gave on API documentation at tcworld India 2015. The workshop covers 3 main areas:
- General overview of API documentation
- Deep dive into REST API documentation
- Deep dive into Javadoc documentation
INTERFACE, by apidays - The 8 Key Components of a Modern API Stack by Iddo G...apidays
INTERFACE, by apidays 2021 - It’s APIs all the way down
June 30, July 1 & 2, 2021
The 8 Key Components of a Modern API Stack
Iddo Gino, CEO at RapidAPI
Practices and tools for building better API (JFall 2013)Peter Hendriks
Een belangrijke voorwaarde om goede en leesbare Java code te schrijven is om gebruik te maken van een goede API. Een goede API helpt ontwikkelaars om sneller hoogwaardige code te schrijven. Het ontwerp van een API is daarom belangrijk, zeker als er grotere systemen worden gerealiseerd in teamverband. Moderne ontwikkeltools als Eclipse, IntelliJ IDEA en FindBugs helpen met het schrijven van goede API, en het detecteren van slecht gebruik. Deze sessie gaat in op de laatste ontwikkelingen en mogelijkheden, inclusief nieuwe taalmogelijkheden in Java 8. Er wordt hierbij gebruik gemaakt van praktische situaties en concrete codevoorbeelden, gebaseerd op echte ervaringen in grote codebases. Met praktische tips en toegankelijke tools kan al een grote stap gemaakt worden om in de praktijk beter met API ontwerp om te gaan!
apidays Paris 2022 - The 12 Facets of the OpenAPI Specification, Steve Sfartz...apidays
apidays Paris 2022 - APIs the next 10 years: Software, Society, Sovereignty, Sustainability
December 14, 15 & 16, 2022
The 12 Facets of the OpenAPI Specification
Steve Sfartz, Principal Architect at Cisco
------
Check out our conferences at https://www.apidays.global/
Do you want to sponsor or talk at one of our conferences?
https://apidays.typeform.com/to/ILJeAaV8
Learn more on APIscene, the global media made by the community for the community:
https://www.apiscene.io
Explore the API ecosystem with the API Landscape:
https://apilandscape.apiscene.io/
Deep dive into the API industry with our reports:
https://www.apidays.global/industry-reports/
Subscribe to our global newsletter:
https://apidays.typeform.com/to/i1MPEW
With Apache Kafka’s rise for event-driven architectures, developers require a specification to design effective event-driven APIs. AsyncAPI has been developed based on OpenAPI to define the endpoints and schemas of brokers and topics. For Kafka applications, the broker’s design to handle high throughput serialized payloads brings challenges for consumers and producers managing the structure of the message. For this reason, a registry becomes critical to achieve schema governance. Apicurio Registry is an end-to-end solution to store API definitions and schemas for Kafka applications. The project includes serializers, deserializers, and additional tooling. The registry supports several types of artifacts including OpenAPI, AsyncAPI, GraphQL, Apache Avro, Google protocol buffers, JSON Schema, Kafka Connect schema, WSDL, and XML Schema (XSD). It also checks them for validity and compatibility.
In this session, we will be covering the following topics:
● The importance of having a contract-first approach to event-driven APIs
● What is AsyncAPI, and how it helps to define Kafka endpoints and schemas
● The Kafka challenges on message structure when serializing and deserializing
● Introduction to Apicurio Registry and schema management for Kafka
● Examples of how to use Apicurio Registry with popular Java frameworks like Spring and Quarkus
Apidays Paris 2023 - Building an Inventory, Maria Teresa Pereira, KPMG Portugalapidays
Apidays Paris 2023 - Software and APIs for Smart, Sustainable and Sovereign Societies
December 6, 7 & 8, 2023
Building an Inventory: How to identify all the APIs hidden in plain sight?
Maria Teresa Pereira, Senior IT Advisor / Pentester - Cybersecurity Services at KPMG Portugal
------
Check out our conferences at https://www.apidays.global/
Do you want to sponsor or talk at one of our conferences?
https://apidays.typeform.com/to/ILJeAaV8
Learn more on APIscene, the global media made by the community for the community:
https://www.apiscene.io
Explore the API ecosystem with the API Landscape:
https://apilandscape.apiscene.io/
Survival Strategies for API Documentation: Presentation to Southwestern Ontar...Tom Johnson
This is a presentation I gave to the Southwestern Ontario STC chapter on API documentation on Feb 2, 2015. For more details, see my blog at http://idratherbewriting.com. You can listen to the recorded presentation here: http://youtu.be/I8rGe2w1sAo.
In this session, Massimo will go through the Swagger specification and some open source tools built on top of Swagger. This includes Swagger editors and how they can be used to create our API stubs,
the Swashbuckle tool to auto-generate swagger.json, to keep it in sync with the server code and to make it discoverable. Finally he will demonstrate the Swagger integration in the API Management space (Azure API Management and Sentinet).
During the last few years, companies started to embrace APIs.
In FRANCE, the API boom really started lately, in 2014.
Today every company wants to build its API.
We had been involved in several API projects : and the goal of this session is to share with you common pitfall that could compromise your API strategy.
The motivation on why and when to use API-First service design. What are the real-life poblems in application development with regard to API's ? And how to solve these using tools like Swagger Editor , Swagger UI and Swagger-codegen. And how can an API Manager tool help to manage the Apllication Lifecycle of your API ( publishing , versioning, registration of consumers , quota's and rate-limiting )
APIsecure - April 6 & 7, 2022
APIsecure is the world’s first conference dedicated to API threat management; bringing together breakers, defenders, and solutions in API security.
The Real World, API Security Edition: When best practices stop being polite and start being real
Sean Boulter, Principal Security Engineer at Salt Security
2022 APIsecure_Learn from the Past, Secure the Present, Plan for the Future: ...APIsecure_ Official
APIsecure - April 6 & 7, 2022
APIsecure is the world’s first conference dedicated to API threat management; bringing together breakers, defenders, and solutions in API security.
Learn from the Past, Secure the Present, Plan for the Future: API Vulnerabilities
Hila Zigman-Zinshtein, VP Product at Noname Security
More Related Content
Similar to 2022 APIsecure_Securing APIs with Open Standards
Oracle API Platform Cloud Service Best Practices & Lessons Learntluisw19
I did this presentation in Split/Croatia on March 2017 where I shared our experiences and insights when implementing the Oracle API Platform Cloud Service.
API Documentation Workshop tcworld India 2015Tom Johnson
This is a workshop I gave on API documentation at tcworld India 2015. The workshop covers 3 main areas:
- General overview of API documentation
- Deep dive into REST API documentation
- Deep dive into Javadoc documentation
INTERFACE, by apidays - The 8 Key Components of a Modern API Stack by Iddo G...apidays
INTERFACE, by apidays 2021 - It’s APIs all the way down
June 30, July 1 & 2, 2021
The 8 Key Components of a Modern API Stack
Iddo Gino, CEO at RapidAPI
Practices and tools for building better API (JFall 2013)Peter Hendriks
Een belangrijke voorwaarde om goede en leesbare Java code te schrijven is om gebruik te maken van een goede API. Een goede API helpt ontwikkelaars om sneller hoogwaardige code te schrijven. Het ontwerp van een API is daarom belangrijk, zeker als er grotere systemen worden gerealiseerd in teamverband. Moderne ontwikkeltools als Eclipse, IntelliJ IDEA en FindBugs helpen met het schrijven van goede API, en het detecteren van slecht gebruik. Deze sessie gaat in op de laatste ontwikkelingen en mogelijkheden, inclusief nieuwe taalmogelijkheden in Java 8. Er wordt hierbij gebruik gemaakt van praktische situaties en concrete codevoorbeelden, gebaseerd op echte ervaringen in grote codebases. Met praktische tips en toegankelijke tools kan al een grote stap gemaakt worden om in de praktijk beter met API ontwerp om te gaan!
apidays Paris 2022 - The 12 Facets of the OpenAPI Specification, Steve Sfartz...apidays
apidays Paris 2022 - APIs the next 10 years: Software, Society, Sovereignty, Sustainability
December 14, 15 & 16, 2022
The 12 Facets of the OpenAPI Specification
Steve Sfartz, Principal Architect at Cisco
------
Check out our conferences at https://www.apidays.global/
Do you want to sponsor or talk at one of our conferences?
https://apidays.typeform.com/to/ILJeAaV8
Learn more on APIscene, the global media made by the community for the community:
https://www.apiscene.io
Explore the API ecosystem with the API Landscape:
https://apilandscape.apiscene.io/
Deep dive into the API industry with our reports:
https://www.apidays.global/industry-reports/
Subscribe to our global newsletter:
https://apidays.typeform.com/to/i1MPEW
With Apache Kafka’s rise for event-driven architectures, developers require a specification to design effective event-driven APIs. AsyncAPI has been developed based on OpenAPI to define the endpoints and schemas of brokers and topics. For Kafka applications, the broker’s design to handle high throughput serialized payloads brings challenges for consumers and producers managing the structure of the message. For this reason, a registry becomes critical to achieve schema governance. Apicurio Registry is an end-to-end solution to store API definitions and schemas for Kafka applications. The project includes serializers, deserializers, and additional tooling. The registry supports several types of artifacts including OpenAPI, AsyncAPI, GraphQL, Apache Avro, Google protocol buffers, JSON Schema, Kafka Connect schema, WSDL, and XML Schema (XSD). It also checks them for validity and compatibility.
In this session, we will be covering the following topics:
● The importance of having a contract-first approach to event-driven APIs
● What is AsyncAPI, and how it helps to define Kafka endpoints and schemas
● The Kafka challenges on message structure when serializing and deserializing
● Introduction to Apicurio Registry and schema management for Kafka
● Examples of how to use Apicurio Registry with popular Java frameworks like Spring and Quarkus
Apidays Paris 2023 - Building an Inventory, Maria Teresa Pereira, KPMG Portugalapidays
Apidays Paris 2023 - Software and APIs for Smart, Sustainable and Sovereign Societies
December 6, 7 & 8, 2023
Building an Inventory: How to identify all the APIs hidden in plain sight?
Maria Teresa Pereira, Senior IT Advisor / Pentester - Cybersecurity Services at KPMG Portugal
------
Check out our conferences at https://www.apidays.global/
Do you want to sponsor or talk at one of our conferences?
https://apidays.typeform.com/to/ILJeAaV8
Learn more on APIscene, the global media made by the community for the community:
https://www.apiscene.io
Explore the API ecosystem with the API Landscape:
https://apilandscape.apiscene.io/
Survival Strategies for API Documentation: Presentation to Southwestern Ontar...Tom Johnson
This is a presentation I gave to the Southwestern Ontario STC chapter on API documentation on Feb 2, 2015. For more details, see my blog at http://idratherbewriting.com. You can listen to the recorded presentation here: http://youtu.be/I8rGe2w1sAo.
In this session, Massimo will go through the Swagger specification and some open source tools built on top of Swagger. This includes Swagger editors and how they can be used to create our API stubs,
the Swashbuckle tool to auto-generate swagger.json, to keep it in sync with the server code and to make it discoverable. Finally he will demonstrate the Swagger integration in the API Management space (Azure API Management and Sentinet).
During the last few years, companies started to embrace APIs.
In FRANCE, the API boom really started lately, in 2014.
Today every company wants to build its API.
We had been involved in several API projects : and the goal of this session is to share with you common pitfall that could compromise your API strategy.
The motivation on why and when to use API-First service design. What are the real-life poblems in application development with regard to API's ? And how to solve these using tools like Swagger Editor , Swagger UI and Swagger-codegen. And how can an API Manager tool help to manage the Apllication Lifecycle of your API ( publishing , versioning, registration of consumers , quota's and rate-limiting )
APIsecure - April 6 & 7, 2022
APIsecure is the world’s first conference dedicated to API threat management; bringing together breakers, defenders, and solutions in API security.
The Real World, API Security Edition: When best practices stop being polite and start being real
Sean Boulter, Principal Security Engineer at Salt Security
2022 APIsecure_Learn from the Past, Secure the Present, Plan for the Future: ...APIsecure_ Official
APIsecure - April 6 & 7, 2022
APIsecure is the world’s first conference dedicated to API threat management; bringing together breakers, defenders, and solutions in API security.
Learn from the Past, Secure the Present, Plan for the Future: API Vulnerabilities
Hila Zigman-Zinshtein, VP Product at Noname Security
APIsecure - April 6 & 7, 2022
APIsecure is the world’s first conference dedicated to API threat management; bringing together breakers, defenders, and solutions in API security.
Shift Left API Security- The right Way
Sanjay Nagaraj, CTO and Co-Founder at Traceable
2022 APIsecure_A day in the life of an API; Fighting the oddsAPIsecure_ Official
APIsecure - April 6 & 7, 2022
APIsecure is the world’s first conference dedicated to API threat management; bringing together breakers, defenders, and solutions in API security.
A day in the life of an API; Fighting the odds
Gil Shulman, VP Technologies at Wib
2022 APIsecure_Passwordless Multi-factor Authentication Security and IdentityAPIsecure_ Official
APIsecure - April 6 & 7, 2022
APIsecure is the world’s first conference dedicated to API threat management; bringing together breakers, defenders, and solutions in API security.
Passwordless Multi-factor Authentication Security and Identity
Sal Karatas, CEO at SAASPASS
APIsecure - April 6 & 7, 2022
APIsecure is the world’s first conference dedicated to API threat management; bringing together breakers, defenders, and solutions in API security.
Securing Large API Ecosystems
Michal Trojanowski, Product Marketing Engineer at Curity AB
APIsecure - April 6 & 7, 2022
APIsecure is the world’s first conference dedicated to API threat management; bringing together breakers, defenders, and solutions in API security.
Quarterly Review of API Vulnerabilities
Ivan Novikov, CEO at Wallarm
APIsecure - April 6 & 7, 2022
APIsecure is the world’s first conference dedicated to API threat management; bringing together breakers, defenders, and solutions in API security.
Top Ten Security Tips for APIs
Tanya Janca, CEO and Founder at WeHackPurple
APIsecure - April 6 & 7, 2022
APIsecure is the world’s first conference dedicated to API threat management; bringing together breakers, defenders, and solutions in API security.
Are your APIs Rugged Enough?
Colin Domoney, Developer Advocate & API Security Researcher at 42Crunch
APIsecure - April 6 & 7, 2022
APIsecure is the world’s first conference dedicated to API threat management; bringing together breakers, defenders, and solutions in API security.
Making webhook APIs secure for enterprise use
Liam Forde, Founder and Head of Product at webhookie
2022 APIsecure_API Security & Fraud Detection - Are you ready?APIsecure_ Official
APIsecure - April 6 & 7, 2022
APIsecure is the world’s first conference dedicated to API threat management; bringing together breakers, defenders, and solutions in API security.
API Security & Fraud Detection - Are you ready ?
Amandine Elbaze, Cyber Security Consultant - API Fraud Detection SOAR at Cybersolutions
Dan Farache, Strategy Advisor for API SECURITY & SOAR
APIsecure - April 6 & 7, 2022
APIsecure is the world’s first conference dedicated to API threat management; bringing together breakers, defenders, and solutions in API security.
Monitoring and Responding to API Breaches
Carolina Ruiz, CEO at Brier & Thorn
2022 APIsecure_Exploiting multi-step business logic vulnerabilities in APIsAPIsecure_ Official
APIsecure - April 6 & 7, 2022
APIsecure is the world’s first conference dedicated to API threat management; bringing together breakers, defenders, and solutions in API security.
Exploiting multi-step business logic vulnerabilities in APIs
Inon Shkedy, API Security Project Lead at OWASP
2022 APIsecure_API Security Testing: The Next Step in Modernizing AppSecAPIsecure_ Official
APIsecure - April 6 & 7, 2022
APIsecure is the world’s first conference dedicated to API threat management; bringing together breakers, defenders, and solutions in API security.
API Security Testing: The Next Step in Modernizing AppSec
Scott Gerlach, Co-Founder, Chief Security Officer at StackHawk
2022 APIsecure_Realizing the Full Cloud Native Potential With a Multi-Layered...APIsecure_ Official
APIsecure - April 6 & 7, 2022
APIsecure is the world’s first conference dedicated to API threat management; bringing together breakers, defenders, and solutions in API security.
Realizing the Full Cloud-Native Potential With a Multi-Layered Defense Approach
Ory Segal, Sr. Director & Product Management at Palo Alto Networks
2022 APIsecure_From Shift Left to Full Circle - A Pragmatic Approach to Catch...APIsecure_ Official
APIsecure - April 6 & 7, 2022
APIsecure is the world’s first conference dedicated to API threat management; bringing together breakers, defenders, and solutions in API security.
From Shift Left to Full Circle - A Pragmatic Approach to Catching Up and Keeping Up With API Security
Chuck Herrin, CTO at WIB
APIsecure - April 6 & 7, 2022
APIsecure is the world’s first conference dedicated to API threat management; bringing together breakers, defenders, and solutions in API security.
Hackers with valid or stolen credentials and API security - beyond OWASP top 10
Bernard Harguindeguy, SVP at Ping Identity
2022 APIsecure_API Abuse - How data breaches now and in the future will use A...APIsecure_ Official
APIsecure - April 6 & 7, 2022
APIsecure is the world’s first conference dedicated to API threat management; bringing together breakers, defenders, and solutions in API security.
API Abuse - How data breaches now and in the future will use API's as the attack vector
Sudeep Padiyar, Product Manager at Traceable
Tim Davis, Director of Product Management at Chime
2022 APIsecure_Understanding API Abuse With Behavioral AnalyticsAPIsecure_ Official
APIsecure - April 6 & 7, 2022
APIsecure is the world’s first conference dedicated to API threat management; bringing together breakers, defenders, and solutions in API security.
Understanding API Abuse With Behavioral Analytics
Giora Engel, CEO and Co-Founder, Neosec
APIsecure - April 6 & 7, 2022
APIsecure is the world’s first conference dedicated to API threat management; bringing together breakers, defenders, and solutions in API security.
Harnessing the Speed of Innovation
Jyoti Bansal, CEO & Founder at Traceable
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf91mobiles
91mobiles recently conducted a Smart TV Buyer Insights Survey in which we asked over 3,000 respondents about the TV they own, aspects they look at on a new TV, and their TV buying preferences.
GraphRAG is All You need? LLM & Knowledge GraphGuy Korland
Guy Korland, CEO and Co-founder of FalkorDB, will review two articles on the integration of language models with knowledge graphs.
1. Unifying Large Language Models and Knowledge Graphs: A Roadmap.
https://arxiv.org/abs/2306.08302
2. Microsoft Research's GraphRAG paper and a review paper on various uses of knowledge graphs:
https://www.microsoft.com/en-us/research/blog/graphrag-unlocking-llm-discovery-on-narrative-private-data/
Securing your Kubernetes cluster_ a step-by-step guide to success !KatiaHIMEUR1
Today, after several years of existence, an extremely active community and an ultra-dynamic ecosystem, Kubernetes has established itself as the de facto standard in container orchestration. Thanks to a wide range of managed services, it has never been so easy to set up a ready-to-use Kubernetes cluster.
However, this ease of use means that the subject of security in Kubernetes is often left for later, or even neglected. This exposes companies to significant risks.
In this talk, I'll show you step-by-step how to secure your Kubernetes cluster for greater peace of mind and reliability.
Accelerate your Kubernetes clusters with Varnish CachingThijs Feryn
A presentation about the usage and availability of Varnish on Kubernetes. This talk explores the capabilities of Varnish caching and shows how to use the Varnish Helm chart to deploy it to Kubernetes.
This presentation was delivered at K8SUG Singapore. See https://feryn.eu/presentations/accelerate-your-kubernetes-clusters-with-varnish-caching-k8sug-singapore-28-2024 for more details.
Connector Corner: Automate dynamic content and events by pushing a buttonDianaGray10
Here is something new! In our next Connector Corner webinar, we will demonstrate how you can use a single workflow to:
Create a campaign using Mailchimp with merge tags/fields
Send an interactive Slack channel message (using buttons)
Have the message received by managers and peers along with a test email for review
But there’s more:
In a second workflow supporting the same use case, you’ll see:
Your campaign sent to target colleagues for approval
If the “Approve” button is clicked, a Jira/Zendesk ticket is created for the marketing design team
But—if the “Reject” button is pushed, colleagues will be alerted via Slack message
Join us to learn more about this new, human-in-the-loop capability, brought to you by Integration Service connectors.
And...
Speakers:
Akshay Agnihotri, Product Manager
Charlie Greenberg, Host
Generating a custom Ruby SDK for your web service or Rails API using Smithyg2nightmarescribd
Have you ever wanted a Ruby client API to communicate with your web service? Smithy is a protocol-agnostic language for defining services and SDKs. Smithy Ruby is an implementation of Smithy that generates a Ruby SDK using a Smithy model. In this talk, we will explore Smithy and Smithy Ruby to learn how to generate custom feature-rich SDKs that can communicate with any web service, such as a Rails JSON API.
Builder.ai Founder Sachin Dev Duggal's Strategic Approach to Create an Innova...Ramesh Iyer
In today's fast-changing business world, Companies that adapt and embrace new ideas often need help to keep up with the competition. However, fostering a culture of innovation takes much work. It takes vision, leadership and willingness to take risks in the right proportion. Sachin Dev Duggal, co-founder of Builder.ai, has perfected the art of this balance, creating a company culture where creativity and growth are nurtured at each stage.
The Art of the Pitch: WordPress Relationships and SalesLaura Byrne
Clients don’t know what they don’t know. What web solutions are right for them? How does WordPress come into the picture? How do you make sure you understand scope and timeline? What do you do if sometime changes?
All these questions and more will be explored as we talk about matching clients’ needs with what your agency offers without pulling teeth or pulling your hair out. Practical tips, and strategies for successful relationship building that leads to closing the deal.
Transcript: Selling digital books in 2024: Insights from industry leaders - T...BookNet Canada
The publishing industry has been selling digital audiobooks and ebooks for over a decade and has found its groove. What’s changed? What has stayed the same? Where do we go from here? Join a group of leading sales peers from across the industry for a conversation about the lessons learned since the popularization of digital books, best practices, digital book supply chain management, and more.
Link to video recording: https://bnctechforum.ca/sessions/selling-digital-books-in-2024-insights-from-industry-leaders/
Presented by BookNet Canada on May 28, 2024, with support from the Department of Canadian Heritage.
Dev Dives: Train smarter, not harder – active learning and UiPath LLMs for do...UiPathCommunity
💥 Speed, accuracy, and scaling – discover the superpowers of GenAI in action with UiPath Document Understanding and Communications Mining™:
See how to accelerate model training and optimize model performance with active learning
Learn about the latest enhancements to out-of-the-box document processing – with little to no training required
Get an exclusive demo of the new family of UiPath LLMs – GenAI models specialized for processing different types of documents and messages
This is a hands-on session specifically designed for automation developers and AI enthusiasts seeking to enhance their knowledge in leveraging the latest intelligent document processing capabilities offered by UiPath.
Speakers:
👨🏫 Andras Palfi, Senior Product Manager, UiPath
👩🏫 Lenka Dulovicova, Product Program Manager, UiPath
Dev Dives: Train smarter, not harder – active learning and UiPath LLMs for do...
2022 APIsecure_Securing APIs with Open Standards
1. Securing APIs with Open Standards
Tips for making and breaking APIs that scale
from the Synack Red Team
2. Vitthal Shinde
Security Engineer, FICO
Synack Red Team
● Security Engineer (4+ Years)
● Builder | Breaker (∞)
Ryan Rutan
Sr. Director of Community
Synack Red Team
● Red Team Director (3+ Years)
● Community & DevRel (12+ years)
● Developer, Architect (20+ years)
● Hacker / Maker / Author (4L1f3)
#forkthislife
SPEAKERS
@SynackRedTeam @ryanrutan @VitthalS @0_1VitthalS
4. Security Through Obscurity (STO)
The belief that a system of any sort
can be secure so long as those
outside of its implementation group
is allowed to find out anything
about its internal mechanisms.
System security should NOT depend on the
secrecy of the implementation or its components.
See Also: https://en.wikipedia.org/wiki/Security_through_obscurity
5. Documentation … How Far We’ve Come
ERA API THEME(S) DOCUMENTATION
1990’s /cgi-bin & Subscription DBs &
“Page Scraping” DOM Wars
WoM/TXT/ZIPor RAR
Reverse Engineer It!
2000’s XML / XML-RPC / SOAP PDF - WSDL/UDDI - Doclets
2010’s REST/JSON + Code Generation PDF - WADL - ”Slate” - Swagger
2020’s Self Discovery (Metadata) - API
Gateways - Composite - Mesh
PDF - ”Slate” - iPaaS -
OpenAPI - Postman Bundles
6. API’s Must Be First-Class Citizens
- Indifference to Downstream Impact
- Non-Interoperable Services / Models
- i.e. Get by URI, have only Email
- Bolt-On API Strategies
- Not Understanding Client Use-Cases
- Picking the Right Framework
- Homogenizing Security Testing
- Obstacles to onboard new testers
7. API Design Security Implications
- Most Common Integration: IFTtT(x1)
- Increased Complexity & Costs
- Unnecessary Integration App Logic
- Try Injection / Logic Bugs
- Unnecessary PII Persistence
- Always Protect Storage
- Makes API Key Leaks More Potent
- Find Ext/Webhook Endpoints
- RoE: In-Scope?
8. OpenAPI Definition Driven Model Helps A Ton …
swagger.io/blog/api-strategy/benefits-of-openapi-api-development/
9. - OpenAPI to GraphQL - https://github.com/IBM/openapi-to-graphql
- Safety net to always try OpenAPI first! Remember: API Gateways
- Platforms Retro-Actively Releasing OpenAPI Descriptors
- Native OpenAPI Project Import into Burp, Postman & Zap
- OpenAPI Fuzzer - https://github.com/matusf/openapi-fuzzer
- Time saved compared to closed box enumeration is exponential
- Tip: Custom script options available for reliable & repeatable results
OpenAPI Third-Party Ecosystem is Thriving
10. Closing the Loop with Developer Relations
- Objective: Bolster Tech Adoption
- Focus:
- Communicate Use-Cases to Tech
Adopters
- Advocate for the Developer Experience
- Channel Tech Adopter Feedback
- Create Strong Community at Scale
- Works With:
- Marketing, Sales, Partners, Engineering,
Product, Support, Customer Success, …
see: TeePublic
11. Three Pillars of Developer Relations
Getting Started
(a.k.a TLDR;)
- Official Use-Cases
- Example Code
- Blogs, Videos
Training
(Documentation)
- Auto-Generated Assets
(Ideally Interactive)
- KB
Support
(How to Get Help)
- FAQ / KB / Contact
- Community / Collab
- VDP
Simple Video (<5 minutes) Interactive OpenAPI Docs FAQ + VDP + Contact
Simple “Developer Experience” In A Box
13. DevRel : HackRel - Two Sides of the Same Coin
DEVREL HACKREL
# of Developers # of Researchers
# of Use-Cases (Most Common Paths) # of Use-Cases (Most & Least Common Path)
# of Supported Integration Languages
- Java, NodeJS, Ruby, GoLang, etc…
# of Supported Automation Languages
- Python / Java, etc…
Time to First Hello World (TtFHW) Time to First API Scan (TtFAS)
Technical Support Process - Clear and Easy Vuln Disclosure Program - Clear and Easy
14. Open Box vs. Closed Box Pentesting Results
- Opportunity Cost for Security Researchers is High
- Cybersecurity gap means less researchers doing more
- Attractive targets are those that can be easily onboarded,
automated and streamlined.
Open Box
- Clearer Scope
- More Diverse Audience
- More Efficient + Attractive
- More Nuanced Research
- Higher Quality Baseline
- Tests Your API
Closed Box
- Opaque Scope
- Less Diverse Audience
- Less Efficient + Attractive
- Less Nuanced Research*
- Lower Quality Baseline
- Tests The Tester
15. What Does It Mean to
Secure Your APIs?
Proposal: Say “YES, I Secure My APIs!” if ALL are TRUE:
- Intentional design & development of APIs to solve use-cases
- Automated documentation and Dev/HackRel enablement artifacts
- Regular, diverse and objective security testing practices
- Curated & maintained index of public/private/protected APIs
16. Takeaways
- Embrace OpenAPI for All New
API Development
- Backport legacy API definitions
- Invest in Proportional &
Repeatable Dev/HackRel UX
- These experiences pay dividends
- Use Open Box Testing
Whenever Possible … Reap
the Awards of Your Efforts!
- Codify Your TTP with Open
API Tools & Scripts
- DevRel Experiences Pave
Roads To Test - Which Path?
- diff: Getting Started & Training
- Don’t Forget About Integration
Middleware Services
- API Keys Stored
In Source Code
- Ext / Webhook Registration
Takeaways
17. Securing APIs with Open Standards
Tips for making and breaking APIs that scale
from the Synack Red Team
Vitthal Shinde
Security Engineer, FICO
Synack Red Team
18. API Recon
● API Documentation
● Older API Documentation
● Developer portal
● Swagger UI
19. Swagger UI
- Common paths ?
https://twitter.com/nahamsec/status/1280246454884331520?lang=en
20. API Recon
● API Documentation
● Older API Documentation
● Developer portal
● Swagger UI
● GraphQL?…Introspection
27. API Recon
● API Documentation
● Older API Documentation leaking older working API calls
● Developer portal
● Swagger UI
● GraphQL?…Introspection
● Mobile application?.....Older versions of APKs, IPA
● WADL, WSDL files
● JS analysis
● Github, public repos….trufflehog
● Common endpoints…./api, /api/v1/, /api/v2/
● Verbose error messages
● Allowed methods….GET/POST/PUT/PATCH/DELETE
● Allowed Content Type ….JSON → XML
● Common parameters….param-miner
● FUZZ….FUZZ….FUZZ
28. Common API Security Vulnerabilities
● Broken Access Control/IDOR
● Sensitive Data exposure
● Mass Assignment
● Rate limiting
● Injection
● Authentication…JWT Vulns?
Vulnerable Application -
https://github.com/VitthalS/ivna
29. Demo/Case Study - Cloud Communication Company
How can I allow users to access objects in S3?
- By default, all objects are private — meaning only the bucket account owner initially
has access to the object.
- Create a presigned URL - Users can interact with objects without the need for AWS
credentials or IAM permissions.
What is presigned url?
- Temp. URLs to share objects inside the bucket
- Using the URL, a user can either READ the object or WRITE an Object (or update an
existing object).
30. Demo/Case Study - Cloud Communication Company
- Cloud based collaboration
solution
- Using API Gateway & S3
- Looks Secure ..?
31. Demo/Case Study - Cloud Communication Company
- User input used to
generate pre-signed
URLs
- Secure access of
full S3 bucket
32.
33.
34.
35.
36.
37. Impact Analysis
Access of full s3 bucket which stores application users sensitive data
such as Files, Documents, Images
Access of files which are marked as private.
Sensitive data such as username/password.
38. Takeaways
Never Trust User input
Document your APIs
Check for exposed APIs
Tip: Target is using AWS S3 to store files? Look for upload/download functionality which uses pre-
signed URLs. Manipulate API parameters to create presigned URL of root URL of bucket and get access
to full S3 bucket.
39. Demo/Case Study
Salesforce IDs
- 5003000000D8cuI
- 000000000000Abc
API < 2.0 - 15-characters and case-sensitive
API <= 2.0 - 15-character case-sensitive ID or the 18-character ID with the 3 extra
characters appended, being case-sensitive.
API 2.5 - 18 characters on the ID (case-insensitive)
https://help.salesforce.com/s/articleView?id=000324087&type=1
40. Demo/Case Study
Where are they used?
Every record, regardless of entity type, has a globally unique identification value in its
ID field which is generated at the time of record creation.
Record ID value will never change, even if the record is deleted and then undeleted.
- userId
- attachmentId
- documentId
- reportId
41. BOLA (IDOR) - Ticket creating portal
Background:
- Ticket creation application where users can create tickets, view them,....CRUD
- Users can add attachments to the ticket
- Application was built using salesforce and using graphQL for APIs
- Ids for creating cases, attachments, users, etc
Example :
5002z000002VEjcAAG
5002z000002VEjXAAW
5002z000002VEjNAAW
5002z000002VEWIAA4
42. Identify the pattern of created resources
Pattern :
5002z000002VE<<random_two_letter_or_number>>AA<<random_one_letter_or_number>>
46. What Next? …..We need
Impact
CRUD Operations on tickets
CRUD Operations on User
PII Leakage
47. Take-Aways
Don’t Rely on Ids….Its not a prevention against BOLA(IDOR)
Implement Authorization + Authentication properly
Implement Rate limiting
Don’t Expose sensitive info in response
Tip: : Come Across application built on Salesforce? Create as many resources as
possible to understand ID pattern and try to bruteforce them
This is a loaded question with many opinions and shades of gray in-between, many of which are valid, but a stark difference exists when determining how to achieve the end-goal.
There are some norms that we can all agree on
HTTPS or Encryption
Using Passwords for Authentication
Using Authorization Frameworks and implementing basics security concepts, such as least privilege.
But then there is the age old question about documentation.
To draw attention or not to draw attention … that is the question.
The year is 2022 and it’s about time we stopped asking this question and all agree that documenting and cataloging your APIs in a good thing.
Let’s take a blast to the past to this little gem … Security Through Obscurity, or STO as some may know it.
As a teenager, when I started my professional career back in the late 90s, I often heard this term thrown around in conference rooms and design reviews, and I wasn’t completely sure if people were just playing a joke on “the new kid”, or not, because it sounded absolutely non-sensical to me.
(CLICK)
It’s one thing for organizations like NIST to have a formal declaration saying that STO is bad, (which you would think wouldn’t be necessary)(CLICK)
But it’s another if in today’s day and age that anyone can still believe that sticking your head in the sand or hiding things and hoping no one figures it out is a viable security practice.
Let’s face it … Hackers are gonna Hack.
If for no other reason, the introspection tools available to hackers these days, both good and bad, are light years ahead of when this belief originated and gained traction.
We’re talking the differences between
WarDialer and Nmap,
Scanning memory dumps on a local machines vs. Burp scanning webapps, and
Direct dial-up vs. modern day broadband
I’m not sure if people realize it, but despite these evolutions, some organizations still embrace the notion of STO implicitly, when they opt to not invest in mature API design and documentation practices.
In this presentation,
we’ll talk about ways that open standards and documentation can help, not hurt, your API security posture, and
how they, as a pentester, can be leveraged to create a more effective and thoughtful plans of attack
and hopefully help stifle some subconscious STO tendencies in the process.
Let’s take a look to see how far we’ve come as it relates to Documentation …
The 90’s were a wild west …
Themes
cgi-bin perl scripts …
local subscription dbs (instead of service calls) …
Page Scraping
Documentation
Argue that primary documentation was spread via word of mouth, on IRC or usenet,
Most of the time you got a Text file of varying verbosity
If you were lucky you got a ZIP or RAR file with images and supporting information
But the tried and true mechanism, was reverse engineering it, which made this a very fun era!
2000’s
Themes
The rise of XML and subsequently XML-RPC and SOAP …
This era was categorically a very RIGID, PAINFUL and LUCRATIVE time in API history =)
Documentation
PDF emerged in the late 1990s and really came on strong for API documentation … especially since it could be password protected.
Java’s Doclet framework was one of the first mainstream interactions
WSDL
2010’s
Themes
Code Generation - API Services are multiplying exponentially as they are getting easier to develop with less code
Documentation
2020’s
Themes
Self-Discovery - API Gateways - Meshes Architectures are rapidly becoming more interconnected and complex
Documentation
How APIs are documented directly relates to their sustainability and securability …
which is why PDFs (even if they are LaTeX generated) continue to be a poor solution
Note: “Slate” a once cool pattern for documenting APIs starts to decline … because it inherently
iPaaS - Documenting how your services are used but not how they should be tested
OpenAPI continues to excel … and Postman Bundles are popular as well because they facilitate automation and tool support for testing at scale downstream.
Key takeaway here … is that without a clear documentation strategy, how will anyone know their API security posture? Are they practicing STO, or are they just blissfully unaware?
Transition … so how do we close the gap!?
Rise of Metadata is apparent … putting that metadata to work for you extends beyond the runtime.
The notion of how we operated in the 1990s is the same way some of us are operating now …
We are collecting more and more meta-data about how our APIs are consumed, discovered and
Services becoming more and more verbose, descriptive and discoverable … how are we harnessing that power?
Not Understanding Client Use-Cases
An in the weeds example that I’ve seen on more than one occasion is a platform defer their API consumption to popular iPaaS venors
Platforms that push customers to use iPaaS vendors for “easy integrations”, but have an API that leverages PATCH
That’s just not my problem syndrome has consequences ….
Bol-On
Today, it’s easy to create classes with annotations … when you see an APIs that dont work together, you
“Not My Problem” Syndrome
Cascading problems when your API is integrated with someone else’s process/platform.
Not Understanding the End-Client or Use-Cases
‘Not My Problem’ Syndrome
“iPaaS” Readiness (Boomi, Zapier, IFTTT, …)
Allow for X-HTTP-Method-Override
Lacking Reflexive Verbosity
API Key without Programmatic Revoke/Refresh (Manual UI)
Not Choosing the Right Platform
Start with OpenAPI - GraphQL - Understand why you want to go
Base64 Hiding Private API Keys in Client Source Code
Wasting time and frustrating customers with atypical client scenarios
SUPPLY CHAIN
!!! You pivot from doing something like a Single Serverless End-Point … to standing up more complicated flows …. Potentially even low-resource VMs which are additional attack surfaces
API Keys Leak
Search for Webhook End-Points and List All
Hostnames
Port and Resource Path Information
If you are lucky, Basic Authentication URL conventions
RULES of Engagement
Stop storing API Keys in your source code … obfuscated or otherwise.
Reasons for these pitfalls are not always apparent, but a common response if that it
Reasons for these pitfalls are not always apparent, but a common response if that it
Allured by Interesting New Technologies
Design
Easy CRUD
Interoperable Services
Mocking
Data Model / Service Congruence
Use-Case Validation
Framework
definition driven approach
Shifts more cycles to detailed design to reap downstream rewards in Testing and Documentation and External Ecosystem
Streamlining Adoption of New APIs by New People with Different Perspectives and TTP
IMPORTANT WHEN IT COMES TO SCALE …
Design: Swagger Editor
Build: Swagger CodeGen & Annotations
QA: Interactive Documentation & Automation
Ecosystem:
Conversion Tools - GraphQL
Swagger YAML/JSON - < 5 Minutes
Server Logs (Lucky) - Custom Grep
FUZZ (
What’s important to realize here is that these assets, while created for Developers/Clients … these are also exceptional resources for Security Researchers
Slack - Simple API Interface, Open Source Tools, In-Product Navigation and Administration, Service Level Control for Tokens!
Twilio - Simple API Interface, Gold-Standard Developer Relations, Product Support
Google - Robust OAuth 2.0 Role Support … rare to see in the wild … exceptional documentation, training, community … and well it’s google
Salesforce - Field level security,
Theme here is that an investment in Developer Relations can:
Make your API more secure … embrace stronger security practices without compromising adoption and education
Let’s face it … up and to the right is golden …
Sad face yellow means you run the risk of losing resources and priority
Bottom left suggests design / use-case alignment may not be in place
Top left is the danger zone where far too many APIs live today.
Note: Least Common Paths (include APIs that are not referenced in the Getting Started Documentation
Closed Box (Lack of Options) - Open API with DevRel get
If you do all these, security through obscurity truly dies.
Use Open API Frameworks With Tool Support (Documentation)
Invest in Adapters / Shims for Legacy Solutions (where possible)
Build Onboarding Materials for Core Use-Cases
Invest In Your TtFHW / TtFAS Experiences
Harness all the efficiencies and productivity of Open API Standards
Invest in DevRel=>HackRel=>TechRel solutions
By understanding the end-client and crafting an intentional developer experience, these materials can be used to onboard fresh perspectives.
Making Things that scale is more than just uptime and performance, it also has to do with incremental sustainability,
Don’t get scared of the light … walk into the light
If you don’t do it for you … do it for your customers .. and the security researchers that will help you keep your platform secure!
Look at the TLDR; experiences … then look at APIs not referenced in those … to see if any interesting data… if in the mainstream, expect better security … but also, expect easier to hide.
Document your APIs … You’ll be glad you did! Otherwise, Security Through Obscurity Wins …
Hello everyone,
I’ll be talking on tips for breaking APis that scale, so we're gonna go over some basic things about API security, I will walk you through my API recon methodology , we will briefly talk about some of the common vulnerabilities in API security, I will be showcasing my developed intentionally vulnerable application & APIs and then some of my unique bugs that I found while doing API Security testing.
So little bit about me...uh...myself vitthal shinde....I am defending FICO as a security engineer, I am a synack red team member. My expertise are in Web, API, Mobile and Infrastructure security.
and views are mine and do not represent my employer.
I will be walking you through my API recon methodology, some of you may or may not have idea about these recon techniques
So where do we start as a BugBounty hunter or as a pentester ? we usually have a limited resources provided to get started on API testing
To increase our attack surface we want to know as much as as possible API endpoints , messages , parameters being used and behaviour of them.
Before starting the assessment I usually look at and get understanding of what are these API endpoints, ……How developers are handling versioning,........ what are the programming languages used and How to authenticate to the APIs.
The more we know the better we can target our attack and easier it is.
Okay, Lets get started, the first thing one should look for is….. [Click] …..API Documentation…..
API documentation which gives us clear picture on how to use them, I have previously experienced where API documentation have more APIs which are hidden or used on server side in the applications so thats where we can get more vulnerabilities.
[Click]
We can look at the Older API documentations which have API calls which are still working and not removed, Developers releases new version of APIs by fixing security vulnerabilities in older ones, Lets say current APIs have prevention against IDOR attacks, wherein deprecated versions might not be protected and we can target them and exploit.
[Click]
One should look for developer portals which may have more info on API calls being used by the application.
[CLICK]
Swagger UI
[Click]
[CLICK]
We can Check if swagger ui is accessible on these kind of commons paths such as /api-docs, /swagger, we can fuzz for these API endpoints.
Lets move on to next one.
[CLICK]
What if Application is using GraphQL?
[CLICK]
Check for graphql instance, there is a list of common endpoints on seclist , we can fuzz for those endpoints
[CLICK]
[CLICK]
As you can see in the screenshot apollo graphql instance is running on path /explorer, which might leak some of the hidden API endpoints.
We can Check if introspection is enabled ? Introspection is the ability to query which resources are available in the current API schema.
[CLICK]
As in the screenshot, Given the API, via sending introspection query in the request, we can see the queries, types, fields, and directives it supports.
So, if introspection is authorized on your target it’s a good news, you will have the possibility to see all useful information to inspect and go deeper on it. We can use tools like GraphQL Voyager to get response in readable format.
[Click]
Okay/ what if introspection is disabled? Fuzz
If introspection is disabled on your target (it should be in a safe world), this is a good opportunity to start finding out what they don’t want us to see. By default, GraphQL backend have a feature for fields and operations suggestions. If you try to query a field but you have made a typo, GraphQL will attempt to suggest fields that are similar to the initial attempt.
Field suggestions is not a vulnerability, but from hacker’s side, this feature can be abused to gain more insight into GraphQL’s schema, especially when Introspection is not allowed.
[Click]
We can increase our attack surface by looking at the mobile applications which may have different API calls from the standard Web application, Also you can find out more endpoints by digging into older versions of APKs, Ipa
[Click]
We can look for wadl, wsdl files and parse them using tools like wsdl parser to find out more endpoints.
[Click]
Next one is JS analysis
Okay, JS Analysis is a skill……. One can find out all the js files used in the application and feed it to linkfinder and similar tools or manually check them to identify API endpoints which may give us hidden API calls to increase our attack surface.
We can use github or public repos to recon and find out sensitive data such as API Keys via feeding repos to trufflehog like tools which may give you API keys, secrets, etc.
As you can see in the disclosed report, jumbcloud API key of starbucks was leaked in github repo.
[CLICK]
Usually APIs are hidden in common endpoints such as /api , /api/v1, v2
[CLICK]
We can Check for verbose error messages thrown when we submit any malicious string in the request, we can dig deep based on that
[CLICK]
Documentation states only POST is allowed, check for other methods such as GET, PUT, PATCH, Delete.
[CLICK]
We can convert content type of request from jSON to XML and check for server response and XML related vulnerabilities.
[CLICK]
Okay, Now we have gathered alot of API endpoints, we can check common parameters and use tools like param-miner to find parameters based on request method, cookies, etc.
[CLICK]
Last golden Tip - FUZZ, FUZZ , FUZZ
We can observe the server behaviour by fuzzing the headers, URLs, and body parameters
Most exploited vulnerabilities no longer come from web server misconfiguration or SQL injections or browser hacks, instead the majority of widely exploited vulnerabilities now come from application logic, access controls, and other non-conventional flaws.
Common Vulnerabilities in API Includes,
Broken Access Control/IDOR
Sensitive Data exposure
Mass Assignment
Rate limiting
Injection
Authentication…JWT Vulns?
To Play around them I have developed a ivna [Intentionally Vulnerable Nodejs Application & APIs], Please do check it out.
We will be looking some of them in the following demo, Lets move into the interesting demo
[CLICK]
So this is a demo/case study about a vulnerability which I found in cloud communication company.
Before we move into the actual vulnerability let me give you all some basic context here
Nowadays most of the companies are utilitizing aws s3 service to store files, so how we get access to our resources of application in a secure manner ?
By default, all the objects stored in S3 buckets are private which means only bucket owner has access to all the resources/files in the S3 bucket.
So to give a access to users data there comes presigned urls. So What are presigned urls ? These are temp. URLs to share files inside the s3 bucket.
Using the URL, a user can either READ the object or WRITE an Object (or update an existing object).
So to brief about this redacted company, Its a cloud based collaboration platform where users can create private groups, add other users, share private documents with them.
After testing many hours in the web application, I decided to check Mobile application, And discovered this vulnerability in Mobile applications API call, where API call of Web version was different and was not vulnerable.
I may require your attention here please , so the flow of this application works as shown in picture,
User access upload/download functionality and API call is triggered to get presigned URL to download/upload files, at the backend Lambda function is triggered and S3 APi is called to generate presigned URL of request object.
And finally user can upload or download file using the presigned URL.
S3 bucket used here was having correct read, write permissions.
Everything looks great, secure right?
Lets look at the attacker's perspective here
I observed that user input was used to generate presigned URLs, so if attacker observes upload/download functionality which is using presigned URLs, it calls the API end point to get presigned URL of requested object.
What if attacker requests a presigned URL for root bucket, as presigned URLs are generated based on user input….. attacker can get access to full S3 bucket.
We got secure access of full s3 bucket.
Ok, enough of theory lets look this API Vulnerability into action.
[CLICK]
Sorry for the bad quality, I have to redact everything for privacy reason.
So, this is the API request which is getting triggered when user uploads his headshot,
If you observe the url parameter in the body, which consist of presigned URL of s3 bucket.
What next ?
Let’s check for s3 buckets misconfiguration
I tried to list bucket , But permissions were in place, so decided to go back to API call
So, As I mentioned earlier what if attacker gives a root URL of bucket in the parameter of this API request, If you can observe here, I have requested presigned URL of root of the bucket and in the response we have received it.
Lets try to access it.
After opening presigned URL from the response I was having access to full S3 bucket.
One can look at the objects of bucket and again generate the presigned URL to get access.
And creds
Lets look into the impact of this vulnerability
So looking at the impact, I was having access to full s3 bucket which stores all the files shared by user in group and documents.
I showed a impact by accessing files which were marked as private, and sensitive data like admin creds.
So this was a misconfiguration where user input was used in the API call, so never trust the user input.
You have to document your APIs and check for exposed APIs.
So, Tip for hackers out there, if Target is using AWS S3 to store files? Look for upload/download functionality which uses presigned URLs. Manipulate API parameters to create presigned URL of root URL of bucket and get access to full S3 bucket.
https://help.salesforce.com/s/articleView?id=000324087&type=1
Okay, Lets move to another interesting demo/case study
Before we move into the vulnerability let me give you a bit of context.
So Salesforce uses Ids in the application and length of these Ids varies based upon API version
API < 2.0 - 15-characters and case-sensitive
API <= 2.0 - 15-character case-sensitive ID or the 18-character ID with the 3 extra characters appended, being case-sensitive.
API 2.5 - 18 characters on the ID (case-insensitive)
Where these Ids are used? In every record
Lets say you are a user in the application so application recognizes you as based on UserID……again if you upload a attachment it will be a attachmentId, etc.
Okay, this demo is about IDOR vulnerability in ticket creating portal
So this application was a ticket creating portal where users can create ticket and admin users can view them for futher processing.
As a user we can do CRUD operations on tickets, also we can add attachments to these tickets.
Application was built using salesforce and using graphql for APIs
Application was giving us these kind of Ids when tickets were created, if you look closely to them you may have already observed the pattern.
So Application was using this pattern where till CAPS E ID remains constant and then there are 2 random letter or number and again AA as a constant and 1 letter or number at the end.
Application was relying on these IDs and there was no authorization checks implemented.
And access control issue was there throughout the application,
After realising these IDs are constant, I replaced the ID of other users and I got access to the details of other users ticket.
Okay, How can we mass leak the data and show impact.
Lets run a intruder by inserting the correct positions and clicking on start attack.
As we have cracked the pattern we have set insertion points based on it
If you can observe in the screenshot, I was able to access applications tickets created by any user
Okay, What Other Impact we can show,
We were able to perform CRUD operations on tickets, users and as shown in screenshot response leak users PII data such as email, address, phone, etc.
SO what are the key takeaways in this vulnerability.
Don’t Rely on Ids….Its not a prevention against BOLA(IDOR) …….Implement Authorization + Authentication properly ………Implement Rate limiting and Don’t Expose unnecessary sensitive info in response
And tip to all hackers out there is if you Came Across application built on salesforce, create as many resources as possible to understand ID pattern and try to bruteforce them
Thank you.