APIs are the building blocks of interoperability on the web and are a key component of scalable and successful technology companies. As externally-consumable APIs expose more information and functionality, ensuring privacy and security of customer data is an increasingly risky proposition. In this session, we’ll talk about some of Slack’s learnings around building Developer APIs and best practices for keeping your APIs safe.
Slides originally for a presentation at the Rocky Mountain Technology Summit. Slightly reduced content.
The document summarizes the OWASP API Security Top 10 - 2019, which outlines the top 10 most critical API security risks. It includes an introduction to the OWASP API Security Top 10 project, release notes on the first edition, a description of the risk rating methodology used, and summaries of the top 10 risks which are: 1) Broken Object Level Authorization, 2) Broken Authentication, 3) Excessive Data Exposure, 4) Lack of Resources & Rate Limiting, 5) Broken Function Level Authorization.
Learn about the OWASP Top 10 Mobile Risks and best practices to avoid mobile application security pitfalls such as insecure data storage, insecure communication, reverse engineering, and more.
These slides were originally presented on a webinar November 2016. Watch the presentation here: https://youtu.be/LuDe3u0cSVs
OWASP Top 10 Vulnerabilities 2017- AppTranaIshan Mathur
Our latest OWASP Top Vulnerabilities Guide updated for new 2017 issues serves as a practical guide to understanding OWASP Top 10 vulnerabilities and preparing a response plan to counter these vulnerabilities.
The Open Web Application Security Project, is an online community that produces freely-available articles, methodologies, documentation, tools, and technologies in the field of web application security.
One of those projects, The OWASP Top Ten, provides a powerful awareness document for web application security. The OWASP Top Ten represents a broad consensus about what the most critical web application security flaws are.
The OWASP team recently released the 2017 revised and updated version of the ten most critical web application security risks and so we’ve created these flash cards for you, your friends, and your colleagues (especially product and engineering :) to test your knowledge and learn more about these important issues.
Company-wide security awareness is a powerful way to improve the overall security of your organization. So adorn your waiting rooms, cubicles, and snack rooms with these flash cards for easy learning and remembrance.
This document outlines the OWASP API Security Top 10 project which identifies the top 10 risks associated with modern application programming interfaces (APIs). It describes each of the top 10 risks, including broken authentication, excessive data exposure, lack of resources and rate limiting, and insufficient logging and monitoring. For each risk, it provides real-world examples of APIs that have been exploited and mitigation strategies are proposed. Additional resources for the project are listed at the end.
The document discusses various techniques for exploiting web applications, beginning with older techniques like exploiting default admin paths, uploading web shells, and SQL injection, and progressing to more modern attacks against content management systems and frameworks. It provides examples of each technique and emphasizes exploiting vulnerabilities like file inclusion and stored procedures to achieve remote code execution. The instructor profile indicates extensive security experience and certifications. The organization Secure D Center is introduced as focusing on cybersecurity services across Southeast Asia.
The document summarizes the OWASP API Security Top 10 - 2019, which outlines the top 10 most critical API security risks. It includes an introduction to the OWASP API Security Top 10 project, release notes on the first edition, a description of the risk rating methodology used, and summaries of the top 10 risks which are: 1) Broken Object Level Authorization, 2) Broken Authentication, 3) Excessive Data Exposure, 4) Lack of Resources & Rate Limiting, 5) Broken Function Level Authorization.
Learn about the OWASP Top 10 Mobile Risks and best practices to avoid mobile application security pitfalls such as insecure data storage, insecure communication, reverse engineering, and more.
These slides were originally presented on a webinar November 2016. Watch the presentation here: https://youtu.be/LuDe3u0cSVs
OWASP Top 10 Vulnerabilities 2017- AppTranaIshan Mathur
Our latest OWASP Top Vulnerabilities Guide updated for new 2017 issues serves as a practical guide to understanding OWASP Top 10 vulnerabilities and preparing a response plan to counter these vulnerabilities.
The Open Web Application Security Project, is an online community that produces freely-available articles, methodologies, documentation, tools, and technologies in the field of web application security.
One of those projects, The OWASP Top Ten, provides a powerful awareness document for web application security. The OWASP Top Ten represents a broad consensus about what the most critical web application security flaws are.
The OWASP team recently released the 2017 revised and updated version of the ten most critical web application security risks and so we’ve created these flash cards for you, your friends, and your colleagues (especially product and engineering :) to test your knowledge and learn more about these important issues.
Company-wide security awareness is a powerful way to improve the overall security of your organization. So adorn your waiting rooms, cubicles, and snack rooms with these flash cards for easy learning and remembrance.
This document outlines the OWASP API Security Top 10 project which identifies the top 10 risks associated with modern application programming interfaces (APIs). It describes each of the top 10 risks, including broken authentication, excessive data exposure, lack of resources and rate limiting, and insufficient logging and monitoring. For each risk, it provides real-world examples of APIs that have been exploited and mitigation strategies are proposed. Additional resources for the project are listed at the end.
The document discusses various techniques for exploiting web applications, beginning with older techniques like exploiting default admin paths, uploading web shells, and SQL injection, and progressing to more modern attacks against content management systems and frameworks. It provides examples of each technique and emphasizes exploiting vulnerabilities like file inclusion and stored procedures to achieve remote code execution. The instructor profile indicates extensive security experience and certifications. The organization Secure D Center is introduced as focusing on cybersecurity services across Southeast Asia.
A walkthrough of web application defense strategies, based around the Open Web Application Security Project's top 10 list. Presented to the Classic City Developers Meetup in August 2017.
Guidelines to protect your APIs from threatsIsabelle Mauny
1) The document discusses securing APIs and provides guidance on a layered approach including application level security, guiding principles like zero trust architecture, and protecting against specific API threats outlined in the OWASP API Security Top 10.
2) It summarizes real stories of API vulnerabilities from companies like Uber, Facebook, and Equifax and provides mitigations for each.
3) The key recommendations are to incorporate API security at design time, conduct security testing of APIs, and automate security through practices like DevSecOps.
Certificate Pinning in Mobile ApplicationsLuca Bongiorni
The document discusses certificate pinning and provides information on implementing it for Android, iOS, and Windows platforms. It describes certificate pinning as associating a host with an expected certificate or public key to prevent man-in-the-middle attacks. The document outlines pros and cons of certificate pinning, and provides code examples and links to resources for implementing pinning on different mobile platforms.
WATCH WEBINAR: https://youtu.be/558MFgH1t9g
JSON Web tokens (JWTs) are used massively in API-based applications as access tokens or to transport information across services. Unfortunately, JWT are often mis-used and incorrectly handled. Massive data breaches have occurred in the last 18 months due to token leakage and lack of proper of validation.
This session focuses on best practices and real world examples of JWT usage, where we cover:
- Typical scenarios where using JWT is a good idea
- Typical scenarios where using JWT is a bad idea!
- Principles of Zero trust architecture and why you should always validate
- Best practices to thoroughly validate JWTs and potential vulnerabilities if you don’t.
- Use cases when encryption may be required for JWT
This document discusses the need for API security as APIs increasingly expose enterprise data and processes both internally and externally. It notes that while APIs may seem invisible without a GUI, they can be easily discovered and are vulnerable to the same threats as web applications if not properly secured. The document advocates for a holistic approach to API security that considers authentication, authorization, integrity, confidentiality and other aspects. It also emphasizes that the right security measures depend on the type of API and calls for collaboration between operations, development, security and business teams to implement proper API security.
API Security - OWASP top 10 for APIs + tips for pentestersInon Shkedy
The document discusses modern application security issues related to APIs. It begins with an overview of common API security risks like SQL injection, XSS, and CSRF. It then focuses on how application security has changed with the transition to modern architectures that are API-focused, use cloud infrastructure, and follow DevOps practices. Key changes discussed include less abstraction layers, clients handling more responsibility, and APIs exposing more data and endpoints directly. The document also summarizes the OWASP API security project and proposed API security top 10 risks. Real attack examples are provided to illustrate broken authorization and authentication vulnerabilities.
API Security Guidelines: Beyond SSL and OAuth.Isabelle Mauny
This document provides guidelines for proper API security. It discusses evolving API security from established perimeters to blurry perimeters. It emphasizes that API security needs to consider authentication, authorization, integrity, confidentiality, availability, audit, and other aspects. It recommends implementing governance, evaluating coverage, establishing risk-based policies, and automating security through the full development cycle.
Protecting Against Vulnerabilities in SharePoint Add-onsImperva
As the pace of Microsoft SharePoint adoption continues, most organizations are turning to third party add-ons to support demands for functionality. It's for these reasons that experts compare SharePoint without add-ons to an iPhone without apps. Third party add-ons, however, arrive pre-packaged with unique security risks -- vulnerabilities that IT cannot directly fix.
This presentation will (1) identify risks associated with using SharePoint plug-ins and web parts developed by third parties (2) describe how hackers target and exploit third-party code using attacks such as SQL injection (3) Introduce a three-layered approach to securing SharePoint.
Addressing the OWASP Mobile Security Threats using XamarinAlec Tucker
You think your mobile app is secure, but is it really? In this session from Xamarin Evolve 2016 in Orlando, Alec will give you the Top 10 mobile threats to be aware of and take an in-depth look at how to mitigate some of these threats using Xamarin and the OWASP Mobile Security Project. A video of the talk is available here: https://youtu.be/rCT9kiA7SE0?list=PLM75ZaNQS_Fb7I6E9MDnMgwW1GGZIijf_
The OWASP Top 10 for Mobile Apps is highly focused on security checks for your mobile apps.
The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications.
This document summarizes common web application security vulnerabilities and methods for securing web applications. It discusses issues like cookie theft, input validation, cross-site scripting, authentication, and more. The document provides examples of vulnerabilities and recommendations for mitigation strategies to help secure web applications.
Application Security not only consists in the use of software, hardware, and procedural methods to protect applications from external threats, it is more than technology, is a path not a destination, it is about risk management and implementing effective countermeasures to identify potential threats and understand that each threat presents a degree of risk.
Once an afterthought in software design, security is becoming an increasingly important concern during development as applications become more frequently accessible over networks and are, as a result, vulnerable to a wide variety of threats. Security measures built into applications and a sound application security routine minimize the likelihood that unauthorized code will be able to manipulate applications to access, steal, modify, or delete sensitive data.
Join up in a tour of various scenarios identifying the basic concepts about Application Security, learning about some of the most recent vulnerabilities and data breaches, as well as examples of how easy it can be to hack you.
Authentication and session management are important aspects of network security. Authentication verifies a user's identity, while session management maintains user access after authentication. Common authentication methods include passwords, multifactor authentication, and digital signatures. Session management uses session IDs and cookies to track authenticated users and can be vulnerable to hijacking attacks. Developers should implement standard security practices like encryption, complex passwords, and short session timeouts to strengthen authentication and prevent session threats.
Rest API Security - A quick understanding of Rest API SecurityMohammed Fazuluddin
This document discusses REST API security methods. It provides an overview of authentication and authorization and describes common security methods like cookie-based authentication, token-based authentication, OAuth, OpenID, and SAML. It then compares OAuth2, OpenID, and SAML and discusses best practices for securing REST APIs like protecting HTTP methods, validating URLs, using security headers, and encoding JSON input.
Checkmarx meetup API Security - API Security top 10 - Erez YalonAdar Weidman
The document summarizes API security topics presented by Erez Yalon at a Checkmarx Meetup event. Yalon discusses how API-based applications are different from traditional apps and deserve their own security focus. He outlines the OWASP API Security Project and the proposed API Security Top 10 risks, including broken object level authorization, excessive data exposure, lack of resources/rate limiting, and improper asset management. Yalon calls for community contributions to further develop the Top 10 and other API security resources.
1) The document discusses various methods for securing RESTful APIs, including choosing the right security protocol, understanding authentication vs authorization, and exploring specific protocols like basic authentication, JSON web tokens, OAuth1.0a, and OAuth2.
2) It provides details on each protocol, including how they work, benefits, structures like the JWT header and payload, and code examples for implementation flows.
3) The key takeaways are to never use basic authentication without TLS, favor HMAC algorithms over bearer tokens, and use OAuth1.0a or OAuth2 (preferably MAC) for authentication, as OAuth is an authorization protocol rather than authentication standard.
This document discusses how to securely introduce secrets into applications using Vault. It describes Vault's capabilities for securing, storing, and controlling access to secrets. There are two main challenges for applications to solve: authentication to Vault and retrieving secrets. The document outlines options for authentication such as deploying tokens, using approle authentication, or TLS client certificates. It emphasizes best practices for secure introduction such as short token lifetimes, limiting access, and monitoring for unauthorized access. Finally, it provides an example workflow for using approle authentication with Vault Agent to get secrets into application memory securely.
A walkthrough of web application defense strategies, based around the Open Web Application Security Project's top 10 list. Presented to the Classic City Developers Meetup in August 2017.
Guidelines to protect your APIs from threatsIsabelle Mauny
1) The document discusses securing APIs and provides guidance on a layered approach including application level security, guiding principles like zero trust architecture, and protecting against specific API threats outlined in the OWASP API Security Top 10.
2) It summarizes real stories of API vulnerabilities from companies like Uber, Facebook, and Equifax and provides mitigations for each.
3) The key recommendations are to incorporate API security at design time, conduct security testing of APIs, and automate security through practices like DevSecOps.
Certificate Pinning in Mobile ApplicationsLuca Bongiorni
The document discusses certificate pinning and provides information on implementing it for Android, iOS, and Windows platforms. It describes certificate pinning as associating a host with an expected certificate or public key to prevent man-in-the-middle attacks. The document outlines pros and cons of certificate pinning, and provides code examples and links to resources for implementing pinning on different mobile platforms.
WATCH WEBINAR: https://youtu.be/558MFgH1t9g
JSON Web tokens (JWTs) are used massively in API-based applications as access tokens or to transport information across services. Unfortunately, JWT are often mis-used and incorrectly handled. Massive data breaches have occurred in the last 18 months due to token leakage and lack of proper of validation.
This session focuses on best practices and real world examples of JWT usage, where we cover:
- Typical scenarios where using JWT is a good idea
- Typical scenarios where using JWT is a bad idea!
- Principles of Zero trust architecture and why you should always validate
- Best practices to thoroughly validate JWTs and potential vulnerabilities if you don’t.
- Use cases when encryption may be required for JWT
This document discusses the need for API security as APIs increasingly expose enterprise data and processes both internally and externally. It notes that while APIs may seem invisible without a GUI, they can be easily discovered and are vulnerable to the same threats as web applications if not properly secured. The document advocates for a holistic approach to API security that considers authentication, authorization, integrity, confidentiality and other aspects. It also emphasizes that the right security measures depend on the type of API and calls for collaboration between operations, development, security and business teams to implement proper API security.
API Security - OWASP top 10 for APIs + tips for pentestersInon Shkedy
The document discusses modern application security issues related to APIs. It begins with an overview of common API security risks like SQL injection, XSS, and CSRF. It then focuses on how application security has changed with the transition to modern architectures that are API-focused, use cloud infrastructure, and follow DevOps practices. Key changes discussed include less abstraction layers, clients handling more responsibility, and APIs exposing more data and endpoints directly. The document also summarizes the OWASP API security project and proposed API security top 10 risks. Real attack examples are provided to illustrate broken authorization and authentication vulnerabilities.
API Security Guidelines: Beyond SSL and OAuth.Isabelle Mauny
This document provides guidelines for proper API security. It discusses evolving API security from established perimeters to blurry perimeters. It emphasizes that API security needs to consider authentication, authorization, integrity, confidentiality, availability, audit, and other aspects. It recommends implementing governance, evaluating coverage, establishing risk-based policies, and automating security through the full development cycle.
Protecting Against Vulnerabilities in SharePoint Add-onsImperva
As the pace of Microsoft SharePoint adoption continues, most organizations are turning to third party add-ons to support demands for functionality. It's for these reasons that experts compare SharePoint without add-ons to an iPhone without apps. Third party add-ons, however, arrive pre-packaged with unique security risks -- vulnerabilities that IT cannot directly fix.
This presentation will (1) identify risks associated with using SharePoint plug-ins and web parts developed by third parties (2) describe how hackers target and exploit third-party code using attacks such as SQL injection (3) Introduce a three-layered approach to securing SharePoint.
Addressing the OWASP Mobile Security Threats using XamarinAlec Tucker
You think your mobile app is secure, but is it really? In this session from Xamarin Evolve 2016 in Orlando, Alec will give you the Top 10 mobile threats to be aware of and take an in-depth look at how to mitigate some of these threats using Xamarin and the OWASP Mobile Security Project. A video of the talk is available here: https://youtu.be/rCT9kiA7SE0?list=PLM75ZaNQS_Fb7I6E9MDnMgwW1GGZIijf_
The OWASP Top 10 for Mobile Apps is highly focused on security checks for your mobile apps.
The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications.
This document summarizes common web application security vulnerabilities and methods for securing web applications. It discusses issues like cookie theft, input validation, cross-site scripting, authentication, and more. The document provides examples of vulnerabilities and recommendations for mitigation strategies to help secure web applications.
Application Security not only consists in the use of software, hardware, and procedural methods to protect applications from external threats, it is more than technology, is a path not a destination, it is about risk management and implementing effective countermeasures to identify potential threats and understand that each threat presents a degree of risk.
Once an afterthought in software design, security is becoming an increasingly important concern during development as applications become more frequently accessible over networks and are, as a result, vulnerable to a wide variety of threats. Security measures built into applications and a sound application security routine minimize the likelihood that unauthorized code will be able to manipulate applications to access, steal, modify, or delete sensitive data.
Join up in a tour of various scenarios identifying the basic concepts about Application Security, learning about some of the most recent vulnerabilities and data breaches, as well as examples of how easy it can be to hack you.
Authentication and session management are important aspects of network security. Authentication verifies a user's identity, while session management maintains user access after authentication. Common authentication methods include passwords, multifactor authentication, and digital signatures. Session management uses session IDs and cookies to track authenticated users and can be vulnerable to hijacking attacks. Developers should implement standard security practices like encryption, complex passwords, and short session timeouts to strengthen authentication and prevent session threats.
Rest API Security - A quick understanding of Rest API SecurityMohammed Fazuluddin
This document discusses REST API security methods. It provides an overview of authentication and authorization and describes common security methods like cookie-based authentication, token-based authentication, OAuth, OpenID, and SAML. It then compares OAuth2, OpenID, and SAML and discusses best practices for securing REST APIs like protecting HTTP methods, validating URLs, using security headers, and encoding JSON input.
Checkmarx meetup API Security - API Security top 10 - Erez YalonAdar Weidman
The document summarizes API security topics presented by Erez Yalon at a Checkmarx Meetup event. Yalon discusses how API-based applications are different from traditional apps and deserve their own security focus. He outlines the OWASP API Security Project and the proposed API Security Top 10 risks, including broken object level authorization, excessive data exposure, lack of resources/rate limiting, and improper asset management. Yalon calls for community contributions to further develop the Top 10 and other API security resources.
1) The document discusses various methods for securing RESTful APIs, including choosing the right security protocol, understanding authentication vs authorization, and exploring specific protocols like basic authentication, JSON web tokens, OAuth1.0a, and OAuth2.
2) It provides details on each protocol, including how they work, benefits, structures like the JWT header and payload, and code examples for implementation flows.
3) The key takeaways are to never use basic authentication without TLS, favor HMAC algorithms over bearer tokens, and use OAuth1.0a or OAuth2 (preferably MAC) for authentication, as OAuth is an authorization protocol rather than authentication standard.
This document discusses how to securely introduce secrets into applications using Vault. It describes Vault's capabilities for securing, storing, and controlling access to secrets. There are two main challenges for applications to solve: authentication to Vault and retrieving secrets. The document outlines options for authentication such as deploying tokens, using approle authentication, or TLS client certificates. It emphasizes best practices for secure introduction such as short token lifetimes, limiting access, and monitoring for unauthorized access. Finally, it provides an example workflow for using approle authentication with Vault Agent to get secrets into application memory securely.
The document summarizes the OWASP Top 10 security risks for web applications. It provides details on each risk such as the types of SQL injection attacks and how to prevent injection flaws. For each risk, it discusses how to determine if an application is vulnerable and recommendations for prevention, including input validation, authentication, authorization, encryption, and keeping components updated. The top risks are injection, broken authentication, XSS, insecure object references, security misconfiguration, sensitive data exposure, missing access controls, CSRF, use of vulnerable components, and unvalidated redirects.
This document discusses public key infrastructure (PKI) and digital certificates. It covers how certificates enable authentication, confidentiality, integrity and non-repudiation. It also discusses certificate authorities, self-signed certificates, common uses of certificates including TLS and code signing, and risks associated with certificates like compromised certificate authorities and vulnerable algorithms. The document provides recommendations around treating certificates as assets, establishing policies, being aware of issues for embedded systems, and monitoring for malware that targets certificates.
Top 10 Web Security Vulnerabilities (OWASP Top 10)Brian Huff
The document summarizes the top 10 security vulnerabilities in web applications according to the Open Web Application Security Project (OWASP). These include injection flaws, cross-site scripting, broken authentication and session management, insecure direct object references, cross-site request forgery, security misconfiguration, insecure cryptographic storage, failure to restrict URL access, insufficient transport layer protection, and unvalidated redirects and forwards. Countermeasures for each vulnerability are also provided.
As companies move towards offering SaaS products in the cloud, it becomes increasingly important to ensure these products are secured by default. This is because customers are no longer in control of their data, but data now resides on a third-party cloud provider.
Security is everyone's responsibility. It is now imperative that these cloud products be built with security in mind from the beginning.
In this session, Anshuman Bhartiya will discuss ways to build secure applications in the cloud.
This document discusses iOS app security best practices. It covers common security breach areas like jailbreak detection, securing sensitive keys, URL schemes, and third-party dependencies. For jailbreak detection, it notes that 100% detection is impossible and the focus should be on making bypassing detection harder. For keys, it recommends hashing and storing them remotely. For URL schemes, it advises moving to universal links and sanitizing input. For dependencies, it notes the risks of incorporating third-party code and importance of staying updated. It concludes by recommending checking the OWASP Mobile Security Testing Guide for vulnerabilities to address.
During our journey towards Serverless Architecture, we’ve found how security in serverless applications is different from the traditional cloud.
Serverless can be a dangerous place unless you prepare yourself with the best practices. There are bullies out there who desperately wants to break into your system.
DDoS attackers, ransomware distributors and all kinds of cyber creeps preying on our databases and poorly configured serverless functions.
Here is the Serverless Security Checklist to ensure serverless security.
This document provides information on secure coding practices for data protection. It discusses classifying data based on sensitivity, encrypting data at rest and in transit, implementing HTTPS securely, using certificate pinning and HTTP Strict Transport Security (HSTS). It also covers least privilege principles, avoiding data leakage, enforcing same-origin policy, and managing cross-origin access controls. The document is a training from an IT security consultant on best practices for secure coding.
A presentation of OWASP's top 10 most common web application security flaws. The content in the slides is sourced from various sources listed in the references section.
The document provides information on how to identify legitimate websites and protect against business identity theft. It discusses how McAfee SiteAdvisor software rates website security and lists signs of legitimate websites like padlock icons and HTTPS protocols. It also outlines 10 steps to counter business identity theft like securing business premises, shredding documents, limiting IT access, and disconnecting ex-employee access.
Eliminating Secret Sprawl in the Cloud with HashiCorp Vault - 07.11.2018HashiCorp
Vault is a tool for centrally managing secrets like passwords, API keys, and certificates. It addresses the problem of "secrets sprawl" where credentials are stored insecurely in multiple places like source code, emails, and configuration files. Vault centralizes secrets management, provides access control and auditing, and generates unique short-lived credentials to reduce risk if a secret is compromised. It also supports encrypting sensitive data for additional protection. Implementing Vault involves deciding where it will run, who will manage encryption keys, which secrets it will store, where audit logs will go, and who will operate and configure the system on an ongoing basis.
Presentation on Top 10 Vulnerabilities in Web ApplicationMd Mahfuzur Rahman
In this presentation I'm trying to describe the "Top 10 Vulnerabilities in Web Application" according to OWASP (Open Web Application Security Project).
--The top 10 security mistakes that developers make
--How to design software with an assurance of security
This document provides an overview of web security. It discusses how 30,000 websites are hacked every day using free hacking tools available online. It notes that SQL injection attacks on Sony led to a data breach of 77 million users. The document introduces OWASP and its top 10 web vulnerabilities. It provides details on the top vulnerability of injection flaws, how they occur, and ways to prevent them such as input validation and output encoding. Broken authentication and sensitive data exposure are also summarized as top vulnerabilities.
Joomla is a free and open source CMS that uses PHP and MySQL. It is vulnerable to attacks like XSS, SQL injection, file execution, insecure authentication, and failure to encrypt sensitive data. Developers should use safe SQL queries, validate all user input, implement secure session handling, encrypt passwords and sensitive data, and restrict access to privileged URLs and functions.
Soteria offers a Cyber Security Health Check for SAP systems that takes 8-10 days to complete. The Health Check evaluates security vulnerabilities, access controls, patching, and common attack vectors. It also checks compliance with the UK Cyber Essentials scheme. Upon completion, Soteria provides a report detailing any issues found and recommendations for remediation. As an optional addition, Soteria can perform a penetration test tailored for common SAP vulnerabilities.
Artificia Intellicence and XPath Extension FunctionsOctavian Nadolu
The purpose of this presentation is to provide an overview of how you can use AI from XSLT, XQuery, Schematron, or XML Refactoring operations, the potential benefits of using AI, and some of the challenges we face.
Measures in SQL (SIGMOD 2024, Santiago, Chile)Julian Hyde
SQL has attained widespread adoption, but Business Intelligence tools still use their own higher level languages based upon a multidimensional paradigm. Composable calculations are what is missing from SQL, and we propose a new kind of column, called a measure, that attaches a calculation to a table. Like regular tables, tables with measures are composable and closed when used in queries.
SQL-with-measures has the power, conciseness and reusability of multidimensional languages but retains SQL semantics. Measure invocations can be expanded in place to simple, clear SQL.
To define the evaluation semantics for measures, we introduce context-sensitive expressions (a way to evaluate multidimensional expressions that is consistent with existing SQL semantics), a concept called evaluation context, and several operations for setting and modifying the evaluation context.
A talk at SIGMOD, June 9–15, 2024, Santiago, Chile
Authors: Julian Hyde (Google) and John Fremlin (Google)
https://doi.org/10.1145/3626246.3653374
Everything You Need to Know About X-Sign: The eSign Functionality of XfilesPr...XfilesPro
Wondering how X-Sign gained popularity in a quick time span? This eSign functionality of XfilesPro DocuPrime has many advancements to offer for Salesforce users. Explore them now!
8 Best Automated Android App Testing Tool and Framework in 2024.pdfkalichargn70th171
Regarding mobile operating systems, two major players dominate our thoughts: Android and iPhone. With Android leading the market, software development companies are focused on delivering apps compatible with this OS. Ensuring an app's functionality across various Android devices, OS versions, and hardware specifications is critical, making Android app testing essential.
E-commerce Development Services- Hornet DynamicsHornet Dynamics
For any business hoping to succeed in the digital age, having a strong online presence is crucial. We offer Ecommerce Development Services that are customized according to your business requirements and client preferences, enabling you to create a dynamic, safe, and user-friendly online store.
Using Query Store in Azure PostgreSQL to Understand Query PerformanceGrant Fritchey
Microsoft has added an excellent new extension in PostgreSQL on their Azure Platform. This session, presented at Posette 2024, covers what Query Store is and the types of information you can get out of it.
UI5con 2024 - Bring Your Own Design SystemPeter Muessig
How do you combine the OpenUI5/SAPUI5 programming model with a design system that makes its controls available as Web Components? Since OpenUI5/SAPUI5 1.120, the framework supports the integration of any Web Components. This makes it possible, for example, to natively embed own Web Components of your design system which are created with Stencil. The integration embeds the Web Components in a way that they can be used naturally in XMLViews, like with standard UI5 controls, and can be bound with data binding. Learn how you can also make use of the Web Components base class in OpenUI5/SAPUI5 to also integrate your Web Components and get inspired by the solution to generate a custom UI5 library providing the Web Components control wrappers for the native ones.
Hand Rolled Applicative User ValidationCode KataPhilip Schwarz
Could you use a simple piece of Scala validation code (granted, a very simplistic one too!) that you can rewrite, now and again, to refresh your basic understanding of Applicative operators <*>, <*, *>?
The goal is not to write perfect code showcasing validation, but rather, to provide a small, rough-and ready exercise to reinforce your muscle-memory.
Despite its grandiose-sounding title, this deck consists of just three slides showing the Scala 3 code to be rewritten whenever the details of the operators begin to fade away.
The code is my rough and ready translation of a Haskell user-validation program found in a book called Finding Success (and Failure) in Haskell - Fall in love with applicative functors.
The Key to Digital Success_ A Comprehensive Guide to Continuous Testing Integ...kalichargn70th171
In today's business landscape, digital integration is ubiquitous, demanding swift innovation as a necessity rather than a luxury. In a fiercely competitive market with heightened customer expectations, the timely launch of flawless digital products is crucial for both acquisition and retention—any delay risks ceding market share to competitors.
Top Benefits of Using Salesforce Healthcare CRM for Patient Management.pdfVALiNTRY360
Salesforce Healthcare CRM, implemented by VALiNTRY360, revolutionizes patient management by enhancing patient engagement, streamlining administrative processes, and improving care coordination. Its advanced analytics, robust security, and seamless integration with telehealth services ensure that healthcare providers can deliver personalized, efficient, and secure patient care. By automating routine tasks and providing actionable insights, Salesforce Healthcare CRM enables healthcare providers to focus on delivering high-quality care, leading to better patient outcomes and higher satisfaction. VALiNTRY360's expertise ensures a tailored solution that meets the unique needs of any healthcare practice, from small clinics to large hospital systems.
For more info visit us https://valintry360.com/solutions/health-life-sciences
4. Every
API
needs
security.
PUBLIC
In endeavoring to expose
functionality to third-parties you blur
the perimeters of your service and
openly expose your data assets and
business capabilities.
INTERNAL / PRIVATE
Without the intention of exposing
your interfaces to third-parties, you
might work under the illusion of
security. You are still at risk.
5. OPEN APIS
68.8% of organizations are
exposing APIs to the public and
their partners.
HUGE SURFACE AREA
On average, companies
manage 363 different public-
facing APIs.
SPECIALIZATION GAP
1 in 4 companies do not treat
API security any differently
than web security.
Wehaveanopenissue.
6. The
internet
isahostile
environment.
Public by default. Gives
everyone access to over 200MM
transactions.
Venmo
An exposed and
unauthenticated API let anyone
access the personal account
details of any customer with
just their cell phone number.
Facebook
Cambridge Analytica acquired
user data through a Facebook
app developer. $37B drop in
market cap.
T-Mobile
10. COVER THE BASICS
Captain Obvious saves the da-ta. Take
the straight-forward steps to not be
an easy target.
01
APPLICATION INTERFACE
The actual APIs need to be developed
with security in mind throughout its
lifecycle.
02
EXTERNAL TOOLING
Expertise often sits outside of your
office and often the “enemy” is a
simple mistake.
04
INFRASTRUCTURE LAYER
Your data is bundled up in to small
packages. Keep them well packed to
ward off would be thieves.
03
Designing SecureAPIs
Ittakesasecurity firstmindset.
11. COVER THE BASICS
Captain Obvious saves the da-ta. Take
the straight-forward steps to not be
an easy target.
01
APPLICATION INTERFACE
The actual APIs need to be developed
with security in mind throughout its
lifecycle.
02
EXTERNAL TOOLING
Expertise often sits outside of your
office and often the “enemy” is a
simple mistake.
04
INFRASTRUCTURE LAYER
Your data is bundled up in to small
packages. Keep them well packed to
ward off would be thieves.
03
Designing SecureAPIs
Haveasecurity firstmindsetat everylayer.
12. SAY NO TO PLAIN-TEXT
It is 2018. There is no excuse.
ALWAYS HASH THEM
Hashing provides a one-way transformation of
text. You store the resulting hash and when a
user attempts to authenticate the comparison is
done by a hash on the input.
DO NOT ROLL YOUR OWN
Argon2, scrypt, bcrypt. There are many libraries
out there. Unless you are a cryptography expert
do not attempt to roll your own.
Encrypt yourpasswords. 🤫
USE A SLOW HASH
Password hashes should be slow to protect
against a “dictionary attack”. The slower the
hash, the longer it takes to run through a
dictionary.
13. HTTPS ALL THE THINGS
It is 2018. There is no excuse. HTTP traffic can
be read by anyone with network access. HTTPS
traffic can only be decrypted by the certificate
owner.
LET’S ENCRYPT IF ON A BUDGET
Let's Encrypt is a free, automated, open-source
certificate authority.
Encrypt trafficusingTLS/SSL. 🔐
14. ENCRYPTION AT REST OR BY DEFAULT
Data stored on servers is considered “at rest”.
This protects against physical theft, but also
protect against any unauthorized access to
data.
STRICTLY MANAGE ACCESS
Many small or startup companies give everyone
direct production access. While this eases
administration and overhead it is simple to
make mistakes.
STORE THE MINIMUM AMOUNT OF DATA
To borrow from the old software adage…
YAGNI. You Ain’t Gonna Need It. Store only the
data you really need to reduce risk.
ENCRYPTION / SECURITY CAN BE EASY
Many database servers can provide
application-level encryption. Google Cloud
Platform encrypts customer data stored
at rest by default.
Besmartaboutdataatrest. 💤
15.
16. 1. INJECTION
An injection of code happens when an attacker
sends invalid data to the application with the
intention of it making an action other than what
was designed.
3. SENSITIVE DATA EXPOSURE
Sensitive data may be compromised without
extra protection, such as encryption at rest or
in transit.
4. XML EXTERNAL ENTITIES (XXE)
External entities can be used to disclose
internal files using the file URI handler, internal
file shares, internal port scanning, remote code
execution, and denial of service attacks.
KnowtheOWASPTopTen. 🎳
2. BROKEN AUTHENTICATION
Weak or broken authentication mechanisms
allow an attacker to gain control over
passwords, keys, or tokens – or even worse – to
gain complete control over entire systems.
17. 5. BROKEN ACCESS CONTROL
Restrictions on what authenticated users are
allowed to do are often not properly enforced.
7. CROSS-SITE SCRIPTING (XSS)
XSS flaws occur whenever an application
includes untrusted data without proper
validation or escaping or updates an existing
web page with user-supplied data.
8. INSECURE DESERIALIZATION
Insecure deserialization often leads to remote
code execution.
KnowtheOWASPTopTen. 🎳
6. SECURITY MISCONFIGURATION
This is commonly a result of leaving default
configurations, incomplete or ad hoc
configurations, open cloud storage,
misconfigured HTTP headers, and verbose
error messages.
18. 9. USING COMPONENTS WITH KNOWN
VULNERABILITIES
Libraries, frameworks, and other components
run with the same privileges as the application.
They need to be kept up-to-date and secure.
11. CHECK PREVIOUS ISSUANCES AND
STAY UP-TO-DATE
The Open Web Application Security Project
updates the top 10 every few years. There are
still gems in the previous notices and there will
be more to come. Security is a full-time and
constant concern.
KnowtheOWASPTopTen. 🎳
10. INSUFFICIENT LOGGING AND
MONITORING
Most breach studies show time to detect a
breach is over 200 days, typically detected by
external parties rather than internal processes
or monitoring.
19. COVER THE BASICS
Captain Obvious saves the da-ta. Take
the straight-forward steps to not be
an easy target.
01
APPLICATION INTERFACE
The actual APIs need to be developed
with security in mind throughout its
lifecycle.
02
EXTERNAL TOOLING
Expertise often sits outside of your
office and often the “enemy” is a
simple mistake.
04
INFRASTRUCTURE LAYER
Your data is bundled up in to small
packages. Keep them well packed to
ward off would be thieves.
03
Designing SecureAPIs
Haveasecurity firstmindsetat everylayer.
20. The most
secureAPI
isonethat
doesnotexist.
ASK WHAT THE USE CASE IS
What problems are you trying to solve
and what functionality are you trying
to expose. Having an API for the sake
of having one is an insecure
proposition.
EXPOSE ONLY WHAT YOU NEED
Just as you should store only the data
that you need for those who need it.
Your API should only expose
information necessary to meet the use
case.
21. Ask your
clientsfor
clean
requests.
MAKE IT HARDER FOR CLIENTS
TO MAKE A MISTAKE
Provide clean documentation, URLs
that do not ask for potentially
sensitive information, ask for
timestamps, and consider publishing
a spec such as OpenAPI.
VERIFY TOWARDS THE TOP
Never trust user input. Never assume
that someone else has verified either
the request or some level of
authorization. Make these checks at
the highest levels possible.
22. IT IS SECURE UNTIL IT IS NOT
Even if your API is meant to be for internal use
or for special clients, you should verify who
that client is.
CONSIDER OAUTH
OAuth allows clients to authenticate from
another service without sharing their password
and allows API providers to grant granular
permissions.
AVOID SESSIONS WHERE POSSIBLE
Sessions leave open windows for attackers to
impersonate a real user. This state is stored
somewhere on the client where you as an API
have little control.
Alwaysauthenticate.
AT LEAST USE BASIC AUTHENTICATION
If you are exposing an internal API and want
the bare minimum consider basic
authentication with TLS / SSL. This is kind of
awful, but better than nothing!
23. SCOPE REQUEST ACCESS
Setup granular permissions for your API that
are scoped only to specific resources or
functionality.
EXPLICITLY GRANT PRIVILEGES
A client’s default access level to any resource in
the system should be DENIED unless they are
explicitly granted a PERMIT.
SEPARATION OF PRIVILEGE
Where logical, a client’s permissions should not
be based on a single condition, but rather a
combination of conditions.
Alwaysauthorize.
PRINCIPLE OF LEAST PRIVILEGE
Similarly, every client must only be able to
access the resources and functionality that are
minimally necessary for their purpose.
24. Aboutthose
keys
and
tokens.
DO NOT ASK FOR THEM IN THE
REQUEST
Keys and tokens being passed around
in URLs are ripe for being sniffed out.
Always use a POST request when
transmitting secrets over HTTP.
ENSURE THEY ARE NON-
SEQUENTIAL
This might seem silly, but use a hard
to guess key or token with a random
component.
25. A TOKEN IS JUST THAT
Once your tokens hit the database they should
have no other use other than access. Do not
reuse them as another identifier.
WATCH THE LOGS
If you employ an aggressive logging strategy
(you should) be sure to redact any secrets in
monitoring or logs.
BURN EXPOSED TOKENS
Actively pursue your rogue tokens. When you
find them delete them. NEVER COMMIT
CREDENTIALS INSIDE CODE. EVER.
Tokensafety.
DELETE UNUSED TOKENS
If a token is no longer in use disable or delete
it. This reduces the chance that an attacker that
finds a token can do anything malicious with it.
26. TOKEN NUKER
At Slack, we methodically seek out and
invalidate customers’ API tokens that have
been accidentally posted publicly. This
happens nearly every day.
WATCH THE LOGS
Most of the time a customer will ask if a token
has been used since published. But you’re
logging all the things so it’s fine.
SAVE YOUR USERS FROM THEMSELVES
Security is hard but you can make it easier for
your users by staying on top of all attack
vectors.
Nuke‘em.
AUTOMATE IT
Token discovery is automated as is the follow-
up notification to the customer.
27. Deliver clean
responses.
PUBLISH A SPEC
Standards, specs, and consistency
help API authors and consumers alike
in sending intentional responses as
well as accepting only the information
necessary.
MIND THE HEADERS
People often focus on the actual
payload of responses, but a lot of
hidden information goes in to HTTP
Headers. Be sure you know what is
being included all the way at the
other end.
28. KISS
Keep it simple Steven. Clear and concise errors
are the most helpful for clients. They also
happen to be the most secure.
DO NOT LEAK YOUR DATA MODELS
A well designed API is focused on client or
developer use cases, not exposing your
underlying architecture.
DO NOT LEAK YOUR STACK TRACES
If you are using a framework, overwrite the
default error pages and make sure you are
running in production mode and not exposing
the underlying code.
Respondwith simple andintentionalerrors.
HIDE YOUR CLUES
Those errors are secure of course, only if you
do not provide hints to a would be attacker
looking for clues.
29. Log
and
Audit
ALLTHE
THINGS.
SERIOUSLY, EVERYTHING
Having a continuous and detailed
stream of events helps not only in
detecting anomalies, but responding
to a potential incident with speed.
STRUCTURE IS HELPFUL
Consider structured logging (JSON
perhaps) to help aide in searching for
the right data.
30. Rate
Limit
ALLTHE
THINGS.
USAGE QUOTAS
The most basic rate limiting schemes
limit clients by allowing clients to
send “x requests per second”.
RESOURCE QUOTAS
More advanced strategies for rate
limiting include throttling based on
the expense of the request or the
frequency of need for the use case.
31. Donotforget
aboutyour
ownlimits.
EVERYTHING IN MODERATION
Many APIs today include event-driven interfaces such as webhooks or other streams. A
sudden forced burst of activity in your service can easily take down your service or leave it
in an otherwise degraded state.
32.
33. IP WHITELISTING
At Slack, we allow customers to configure a set
of static IPs from which we will know that they
are sending traffic.
MUTUAL TLS
If you can run your own TLS-terminating server,
you can obtain a shared secret with another
individual organization to verify their identity.
INTERNAL BLACKLISTING
Over time you can collect a list of bad actors
and immediately reject their traffic. This is a
necessarily a cat and mouse game but there are
smart ways to respond.
Provide methodstotrusttraffic.
REQUEST SIGNING
You can use a pre-determined shared secret to
hash a request against.
34. COVER THE BASICS
Captain Obvious saves the da-ta. Take
the straight-forward steps to not be
an easy target.
01
APPLICATION INTERFACE
The actual APIs need to be developed
with security in mind throughout its
lifecycle.
02
EXTERNAL TOOLING
Expertise often sits outside of your
office and often the “enemy” is a
simple mistake.
04
INFRASTRUCTURE LAYER
Your data is bundled up in to small
packages. Keep them well packed to
ward off would be thieves.
03
Designing SecureAPIs
Haveasecurity firstmindsetat everylayer.
35. Test
Test
Test
AUTOMATE ANYTHING YOU CAN
Test your APIs constantly and preferably at their furthest stage from production. A spec
like OpenAPI and following a JSON Schema can help you detect changes to your API and
unintended exposure of data.
36. SERVER BASICS
Lock down your ports and server access. API
security depends on overall security of your
entire stack.
NETWORK FIREWALL
Tune and configure your connectivity policies
to monitor and protect your application
servers.
WEB APPLICATION FIREWALL
Use IaaS or other software to monitor and
block traffic and protect against DDoS attacks.
DeploysmartinfratoshieldyourAPIs.
API GATEWAY
Isolate your API traffic. This can either be done
by code architecture or putting another layer of
abstraction in front of the rest of your
infrastructure.
37. COVER THE BASICS
Captain Obvious saves the da-ta. Take
the straight-forward steps to not be
an easy target.
01
APPLICATION INTERFACE
The actual APIs need to be developed
with security in mind throughout its
lifecycle.
02
EXTERNAL FACTORS
Expertise often sits outside of your
office and often the “enemy” is a
simple mistake.
04
INFRASTRUCTURE LAYER
Your data is bundled up in to small
packages. Keep them well packed to
ward off would be thieves.
03
Designing SecureAPIs
Haveasecurity firstmindsetat everylayer.
38. Donotroll
yourown.
LEAN ON OPEN SOURCE
There are a plethora of Open Source tools and libraries that relate to secure
implementations and to ensure API security. The community at large shares expertise,
helps find bugs, and wider usage helps test in the wild. Don’t forget to keep these tools
and libraries up-to-date. Use with caution of course…
39. Enforce
policies ina
consistentand
timely manner.
POLICY AND LEGAL
At Slack, our Policy and Legal teams are also included in the Developer Platform and
Security cross-functional groups. Terms of Services and Acceptable Use Case policies are
increasingly important as you expose more data. Action needs to be taken swiftly and
applied consistently.
40.
41. Partner
acrossthe
organization.
SECURITY DEVELOPMENT LIFECYCLE
Our product and infrastructure
engineering teams have partnered
with the security org to review projects.
This is both procedural and educational!
SECURITY WEEK
Once a year, Slack holds a security week
where we compete in Capture The Flag,
a security training platform, and hold
other classes like lock-picking.
42. APP DIRECTORY REVIEW
This is a requirement of listing. It is a
combination of automated scanning processes,
limiting scopes, and manual reviews of
architecture, authentication, and misuse.
SHARE BEST PRACTICES
We come across common mistakes and
patterns and these go in to not only our
documentation, but in hands-on help at our
developer focused events.
Partnerwithyourdevelopers.
CHECK AGAIN
We regularly follow up with scans and employ
external vendors to also do periodic reviews.
44. REAL ATTACKS
Even if you have an internal security
organization, it is always to get real help from
the outside. Outside pen-testing vendors try to
expose real vulnerabilities without inside
knowledge.
BE PREPARED AND WORK CLOSELY
The best case scenario is that you have paid a
vendor money and they have found nothing.
They will certainly try. The worst case is you will
need to be prepared to respond.
MULTIPLE VENDORS
The strengths, quality, and speed of reporting
and assessment varies widely. If you have the
budget, compare multiple pen-testing vendors.
Asktobehacked.
SAFE ATTACKS
Generally external security testing vendors will
run automation in non-critical business hours or
will limit the speed of their automation. Their
exploits will also be relatively “safe”.
45. BUG BOUNTY
Real vulnerabilities and reports from external
security researchers. Slack is listed on
HackerOne.
PAY
Over the last 4 years, Slack has paid out over
$300k in rewards. You can set the tiers and
payouts.
ESTABLISH SLAS
Once bugs come in, make sure there is
accountability in getting security issues
resolved expediently.
Asktobehackedmore.
RESPOND
We judge the quality of our communication
with researchers by our response times. In
addition to accountability, it builds overall trust
in the community.
46.
47. Plan
your
response.
HAVE A RUNBOOK
Have step-by-step procedures with
Directly Responsible Individuals and
communication plans. Hopefully you
will never need this but it will be
crucial if you do.
PRACTICE MAKES PERFECT
Runbooks are only useful when you’re
running. Consider running drills for
incidents, whether operational or
security to make sure you work out
those response muscles.