This document discusses using intrusion detection systems (IDS) to monitor web applications for security threats. It explains that IDS can be used to detect both known and unknown attacks. A positive security model uses whitelists to allow only known good traffic while a negative model uses blacklists to detect malicious patterns. The document then examines how different types of attacks from the OWASP Top 10 could be detected, such as cross-site scripting, SQL injection, and session hijacking. It recommends a three-tiered approach to security monitoring that involves logging all activity, detailed logs of attacks, and alerts of potential intrusions.
Insecure Direct Object References occur when an application provides direct access to objects based on user-supplied input. As a result of this vulnerability attackers can bypass authorization and access resources in the system directly, for example database records or files.
This presentation explain how to discover this vulnerability in application, how to test and how to mitigate the risk.
Understand basics of testing security aspects like passwords, robots.txt. Understand SQL Injection and XSS attacks. Automation of them using ZAP proxy tool.
This document summarizes potential vulnerabilities in how different layers of a web application process data. It discusses how each layer - including hardware, operating system, browser, network, web server, framework, application and database - accepts inputs and produces outputs that could be leveraged maliciously if not properly validated. Many real-world examples are provided of how inputs passed between layers can bypass validation checks if the layers' data processing rules are not well understood by developers. The key message is that all variables not explicitly set in code should be considered untrusted.
Nowaday, embedded systems are widely used and connected to networks, especially the Internet. This become the Internet of Things (IoT) era. When a device is on the Internet, it may be attacked or intentionally used by an unauthorized persons. How can we make IoT devices secure under the limited resources?
This presentation will explain the lesson learned from banking and card payment industry how the embedded systems process financial transaction reliably and securely.
This document describes Skyfall, a web vulnerability scanner based on Skipfish. Skyfall is designed for high performance and ease of use. It implements a variety of security checks including tests for SQL injection, XSS vulnerabilities, file inclusion issues, and more. The scanner can perform over 500 requests per second and has a small memory footprint. Features include adaptive crawling, automatic wordlist generation, and filtering of false positives in reports. The document provides details on Skyfall's implemented tests and demonstrates its scanning capabilities.
Internet banking safeguards vulnerabilities - OWASP AppSec EU 2016SecuRing
Presentation from OWASP AppSec EU 2016 Rome
All internet banking applications are different but all of them share many common security features which are very specific to this domain of web applications, such as:
• transaction limits,
• notifications via SMS or e-mail,
• authorization schemes,
• trusted recipients,
• two-factor authentication and transaction authorization,
• pay-by-links,
• communication channel activation (e.g. mobile banking or IVR),
It is not very rare that these safeguards are incorrectly implemented leaving the internet banking application vulnerable.
Last year at AppSec EU I was talking about common vulnerabilities in e-banking transaction authorization. As a follow-up to this presentation, OWASP Transaction Authorization Cheat Sheet was published and gained some attention from banks, developers and testers. This year, I want to continue and expand this work to other security mechanisms which are specific and common to internet banking applications. During my presentation I want to show some common mistakes made during implementation of the abovementioned internet banking safeguards.
As a follow-up, I am planning to expand OWASP Transaction Authorization Cheat Sheet to Internet Banking Cheat Sheet which will include guidelines for secure implementation of all security mechanisms common to contemporary internet banking applications. At the end of my presentation, I also want to discuss the idea of expanding key OWASP materials such as ASVS, Testing Guide, Development guide by adding appendixes specific to group of applications (such as internet/mobile banking, e-commerce, etc.).
Automation attacks are currently plaguing organizations in industries ranging from financial to retail, to gaming & entertainment. These attacks exploit stolen credential leaks, black market & custom attack toolkits, and massively scalable infrastructure to launch widely distributed attacks that are extremely difficult to detect, let alone attribute. In this presentation we will inform the audience of the scale of this problem, discuss a detection methodology to counter these attacks, and walk through 3 real-world examples of how attackers created and monetized the distributed infrastructure they require to launch these attacks.
HackInBo2k16 - Threat Intelligence and Malware AnalysisAntonio Parata
Threat intelligence and malware analysis are two sides of the same coin. Threat intelligence involves gathering information from various sources like open source intelligence (OSINT), internal network monitoring, and commercial threat feeds. This information can be used to understand emerging threats and inform an organization's response. Malware analysis involves reverse engineering malware samples to understand how they work and extract indicators like command and control servers and drop zones. Understanding common malware components like packers, loaders, and payloads can help focus analysis. Banking malware often uses dynamic configurations and web injections to target users and steal credentials. Both threat intelligence and malware analysis are important for increasing security awareness and protecting networks from emerging threats.
Insecure Direct Object References occur when an application provides direct access to objects based on user-supplied input. As a result of this vulnerability attackers can bypass authorization and access resources in the system directly, for example database records or files.
This presentation explain how to discover this vulnerability in application, how to test and how to mitigate the risk.
Understand basics of testing security aspects like passwords, robots.txt. Understand SQL Injection and XSS attacks. Automation of them using ZAP proxy tool.
This document summarizes potential vulnerabilities in how different layers of a web application process data. It discusses how each layer - including hardware, operating system, browser, network, web server, framework, application and database - accepts inputs and produces outputs that could be leveraged maliciously if not properly validated. Many real-world examples are provided of how inputs passed between layers can bypass validation checks if the layers' data processing rules are not well understood by developers. The key message is that all variables not explicitly set in code should be considered untrusted.
Nowaday, embedded systems are widely used and connected to networks, especially the Internet. This become the Internet of Things (IoT) era. When a device is on the Internet, it may be attacked or intentionally used by an unauthorized persons. How can we make IoT devices secure under the limited resources?
This presentation will explain the lesson learned from banking and card payment industry how the embedded systems process financial transaction reliably and securely.
This document describes Skyfall, a web vulnerability scanner based on Skipfish. Skyfall is designed for high performance and ease of use. It implements a variety of security checks including tests for SQL injection, XSS vulnerabilities, file inclusion issues, and more. The scanner can perform over 500 requests per second and has a small memory footprint. Features include adaptive crawling, automatic wordlist generation, and filtering of false positives in reports. The document provides details on Skyfall's implemented tests and demonstrates its scanning capabilities.
Internet banking safeguards vulnerabilities - OWASP AppSec EU 2016SecuRing
Presentation from OWASP AppSec EU 2016 Rome
All internet banking applications are different but all of them share many common security features which are very specific to this domain of web applications, such as:
• transaction limits,
• notifications via SMS or e-mail,
• authorization schemes,
• trusted recipients,
• two-factor authentication and transaction authorization,
• pay-by-links,
• communication channel activation (e.g. mobile banking or IVR),
It is not very rare that these safeguards are incorrectly implemented leaving the internet banking application vulnerable.
Last year at AppSec EU I was talking about common vulnerabilities in e-banking transaction authorization. As a follow-up to this presentation, OWASP Transaction Authorization Cheat Sheet was published and gained some attention from banks, developers and testers. This year, I want to continue and expand this work to other security mechanisms which are specific and common to internet banking applications. During my presentation I want to show some common mistakes made during implementation of the abovementioned internet banking safeguards.
As a follow-up, I am planning to expand OWASP Transaction Authorization Cheat Sheet to Internet Banking Cheat Sheet which will include guidelines for secure implementation of all security mechanisms common to contemporary internet banking applications. At the end of my presentation, I also want to discuss the idea of expanding key OWASP materials such as ASVS, Testing Guide, Development guide by adding appendixes specific to group of applications (such as internet/mobile banking, e-commerce, etc.).
Automation attacks are currently plaguing organizations in industries ranging from financial to retail, to gaming & entertainment. These attacks exploit stolen credential leaks, black market & custom attack toolkits, and massively scalable infrastructure to launch widely distributed attacks that are extremely difficult to detect, let alone attribute. In this presentation we will inform the audience of the scale of this problem, discuss a detection methodology to counter these attacks, and walk through 3 real-world examples of how attackers created and monetized the distributed infrastructure they require to launch these attacks.
HackInBo2k16 - Threat Intelligence and Malware AnalysisAntonio Parata
Threat intelligence and malware analysis are two sides of the same coin. Threat intelligence involves gathering information from various sources like open source intelligence (OSINT), internal network monitoring, and commercial threat feeds. This information can be used to understand emerging threats and inform an organization's response. Malware analysis involves reverse engineering malware samples to understand how they work and extract indicators like command and control servers and drop zones. Understanding common malware components like packers, loaders, and payloads can help focus analysis. Banking malware often uses dynamic configurations and web injections to target users and steal credentials. Both threat intelligence and malware analysis are important for increasing security awareness and protecting networks from emerging threats.
This article summarizes 7 common PHP security blunders:
1) Unvalidated input errors, where user input is not checked and can enable exploits. Proper validation of expected data types is needed.
2) Access control flaws, where restricted pages can be accessed without authentication. Credentials should be checked on every page.
3) Session ID protection issues, where IDs can be hijacked. IDs should be regenerated on login and sensitive data not stored in sessions.
4) Cross-site scripting flaws, where malicious code can be inserted and run as other users. User input must be escaped before displaying.
5) SQL injection vulnerabilities, where user input is inserted unsafely into SQL queries allowing unauthorized data
Tarifa Leones del Escogido Temporada 2016-2017Odalis Santiago
La Unión Europea ha acordado un paquete de sanciones contra Rusia por su invasión de Ucrania. Las sanciones incluyen restricciones a las transacciones con bancos rusos clave y la prohibición de la venta de aviones y equipos a Rusia. Los líderes de la UE también acordaron excluir a varios bancos rusos del sistema SWIFT de mensajería financiera.
This document discusses using intrusion detection systems (IDS) to monitor web applications for security threats. It explains that IDS can be used to detect both known and unknown attacks by logging all activity and applying both whitelist and blacklist rules. The document also provides examples of how common vulnerabilities like SQL injection, XSS, and session hijacking could be detected. It recommends a tiered approach to IDS with different levels of logging and alerting to balance security and manageability.
Trabajo de laboratorio sobre Actividad Catalasa - Laboratory work on catalas...pschwarzbaum
Actividad diseñada a introducir a los alumnos en actividades de laboratorio.
Los alumnos deben hacer un homogenato de higado y luego utilizarlo para verificar la reaccion mediada por la enzima catalasa. Deben realizar controles adecuados y trabajar en un ambiente seguro.
This document discusses using intrusion detection systems (IDS) to monitor web applications for security threats. It explains that IDS can be used to detect both known and unknown attacks. A positive security model uses whitelists to allow only known good traffic while a negative model uses blacklists to detect malicious patterns. The document then examines how different types of attacks from the OWASP Top 10 could be detected, such as XSS, SQL injection, and session hijacking. It advocates a three-tiered approach to security monitoring with different levels of logging and alerting.
This document discusses using intrusion detection systems (IDS) to monitor web applications for security threats. It explains that IDS can be used to detect both known and unknown attacks. A positive security model uses whitelists to allow only known good traffic while a negative model uses blacklists to detect malicious patterns. The document then examines how different types of attacks from the OWASP Top 10 could be detected, such as cross-site scripting, SQL injection, and session hijacking. It recommends a three-tiered approach to security monitoring that involves logging all activity, detailed logs of attacks, and alerts of possible intrusions.
This document discusses using intrusion detection systems (IDS) to monitor web applications for security threats. It explains that IDS can be used to detect both known and unknown attacks by logging all activity and applying both whitelist and blacklist rules. The document also provides examples of how different types of attacks could be detected, such as SQL injection, cross-site scripting, and session hijacking. It recommends a three-tiered approach to IDS that involves logging all activity, detailed logging of detected attacks, and flagging possible intrusions for manual review.
This document discusses using intrusion detection systems (IDS) to monitor web applications for security threats. It explains that IDS can be used to detect both known and unknown attacks by logging all activity and applying both whitelist and blacklist rules. The document also provides examples of how different types of attacks could be detected, such as SQL injection, cross-site scripting, and session hijacking. It recommends a three-tiered approach to IDS that involves logging all activity, detailed logging of detected attacks, and flagging possible intrusions for manual review.
This document discusses using intrusion detection systems (IDS) to monitor web applications for security threats. It explains that IDS can be used to detect both known and unknown attacks by logging all activity and applying both whitelist and blacklist rules. The document also provides examples of how different types of attacks could be detected, such as SQL injection, cross-site scripting, and session hijacking. It recommends a three-tiered approach to IDS that involves logging all activity, detailed logging of detected attacks, and flagging possible intrusions for manual review.
This document discusses using intrusion detection systems (IDS) to monitor web applications for security threats. It explains that IDS can be used to detect both known and unknown attacks by logging all activity and applying both whitelist and blacklist rules. The document also provides examples of how different types of attacks could be detected, such as SQL injection, cross-site scripting, and session hijacking. It recommends a three-tiered approach to IDS that involves logging all activity, detailed logging of detected attacks, and flagging possible intrusions for manual review.
This document discusses using intrusion detection systems (IDS) to monitor web applications for security threats. It explains that IDS can be used to detect both known and unknown attacks by logging all activity and applying both whitelist and blacklist rules. The document also provides examples of how common vulnerabilities like SQL injection, XSS, and session hijacking could be detected. It recommends a tiered approach to IDS with different levels of logging, alerting, and blocking of suspicious traffic.
This document discusses using intrusion detection systems (IDS) to monitor web applications for security threats. It explains that IDS can be used to detect both known and unknown attacks. A positive security model uses whitelists to allow only known good traffic, but this has limitations for complex data types. A negative security model uses blacklists of known attack patterns, but cannot detect all unknown attacks. The document advocates a tiered approach to security logging and monitoring with increasing levels of detail and prioritization of alerts.
This document discusses using intrusion detection systems (IDS) to monitor web applications for security threats. It explains that IDS can be used to detect both known and unknown attacks by logging all activity and applying both whitelist and blacklist rules. The document also provides examples of how different types of attacks could be detected, such as SQL injection, cross-site scripting, and session hijacking. It recommends a three-tiered approach to IDS that involves logging all activity, detailed logging of detected attacks, and flagging possible intrusions for manual review.
This document discusses using intrusion detection systems (IDS) to monitor web applications for security threats. It explains that IDS can be used to detect both known and unknown attacks by logging all activity and applying both whitelist and blacklist rules. The document also provides examples of how different types of attacks could be detected, such as SQL injection, cross-site scripting, and session hijacking. It recommends a three-tiered approach to IDS that involves logging all activity, detailed logging of detected attacks, and flagging possible intrusions for manual review.
In this presentation, you can learn many practical resources about WAF, how you can create your WAF, and how you can bypass protections in common WAFs.
This document discusses various application security topics such as downloading files securely, handling secrets and temporary tokens, implementing third-party sites securely, privacy risks of third-party monitoring and analytics on sensitive pages, push notifications versus SMS, securely using FFmpeg and ImageMagick, serving user content securely, implementing cryptography securely, and applying rate limits. It provides advice on how to address each topic securely, such as only allowing certain schemes, ports and domains for file downloads, short expiration times for temporary tokens, sandboxing or isolating third-party components, and not implementing one's own crypto.
This article summarizes 7 common PHP security blunders:
1) Unvalidated input errors, where user input is not checked and can enable exploits. Proper validation of expected data types is needed.
2) Access control flaws, where restricted pages can be accessed without authentication. Credentials should be checked on every page.
3) Session ID protection issues, where IDs can be hijacked. IDs should be regenerated on login and sensitive data not stored in sessions.
4) Cross-site scripting flaws, where malicious code can be inserted and run as other users. User input must be escaped before displaying.
5) SQL injection vulnerabilities, where user input is inserted unsafely into SQL queries allowing unauthorized data
Tarifa Leones del Escogido Temporada 2016-2017Odalis Santiago
La Unión Europea ha acordado un paquete de sanciones contra Rusia por su invasión de Ucrania. Las sanciones incluyen restricciones a las transacciones con bancos rusos clave y la prohibición de la venta de aviones y equipos a Rusia. Los líderes de la UE también acordaron excluir a varios bancos rusos del sistema SWIFT de mensajería financiera.
This document discusses using intrusion detection systems (IDS) to monitor web applications for security threats. It explains that IDS can be used to detect both known and unknown attacks by logging all activity and applying both whitelist and blacklist rules. The document also provides examples of how common vulnerabilities like SQL injection, XSS, and session hijacking could be detected. It recommends a tiered approach to IDS with different levels of logging and alerting to balance security and manageability.
Trabajo de laboratorio sobre Actividad Catalasa - Laboratory work on catalas...pschwarzbaum
Actividad diseñada a introducir a los alumnos en actividades de laboratorio.
Los alumnos deben hacer un homogenato de higado y luego utilizarlo para verificar la reaccion mediada por la enzima catalasa. Deben realizar controles adecuados y trabajar en un ambiente seguro.
This document discusses using intrusion detection systems (IDS) to monitor web applications for security threats. It explains that IDS can be used to detect both known and unknown attacks. A positive security model uses whitelists to allow only known good traffic while a negative model uses blacklists to detect malicious patterns. The document then examines how different types of attacks from the OWASP Top 10 could be detected, such as XSS, SQL injection, and session hijacking. It advocates a three-tiered approach to security monitoring with different levels of logging and alerting.
This document discusses using intrusion detection systems (IDS) to monitor web applications for security threats. It explains that IDS can be used to detect both known and unknown attacks. A positive security model uses whitelists to allow only known good traffic while a negative model uses blacklists to detect malicious patterns. The document then examines how different types of attacks from the OWASP Top 10 could be detected, such as cross-site scripting, SQL injection, and session hijacking. It recommends a three-tiered approach to security monitoring that involves logging all activity, detailed logs of attacks, and alerts of possible intrusions.
This document discusses using intrusion detection systems (IDS) to monitor web applications for security threats. It explains that IDS can be used to detect both known and unknown attacks by logging all activity and applying both whitelist and blacklist rules. The document also provides examples of how different types of attacks could be detected, such as SQL injection, cross-site scripting, and session hijacking. It recommends a three-tiered approach to IDS that involves logging all activity, detailed logging of detected attacks, and flagging possible intrusions for manual review.
This document discusses using intrusion detection systems (IDS) to monitor web applications for security threats. It explains that IDS can be used to detect both known and unknown attacks by logging all activity and applying both whitelist and blacklist rules. The document also provides examples of how different types of attacks could be detected, such as SQL injection, cross-site scripting, and session hijacking. It recommends a three-tiered approach to IDS that involves logging all activity, detailed logging of detected attacks, and flagging possible intrusions for manual review.
This document discusses using intrusion detection systems (IDS) to monitor web applications for security threats. It explains that IDS can be used to detect both known and unknown attacks by logging all activity and applying both whitelist and blacklist rules. The document also provides examples of how different types of attacks could be detected, such as SQL injection, cross-site scripting, and session hijacking. It recommends a three-tiered approach to IDS that involves logging all activity, detailed logging of detected attacks, and flagging possible intrusions for manual review.
This document discusses using intrusion detection systems (IDS) to monitor web applications for security threats. It explains that IDS can be used to detect both known and unknown attacks by logging all activity and applying both whitelist and blacklist rules. The document also provides examples of how different types of attacks could be detected, such as SQL injection, cross-site scripting, and session hijacking. It recommends a three-tiered approach to IDS that involves logging all activity, detailed logging of detected attacks, and flagging possible intrusions for manual review.
This document discusses using intrusion detection systems (IDS) to monitor web applications for security threats. It explains that IDS can be used to detect both known and unknown attacks by logging all activity and applying both whitelist and blacklist rules. The document also provides examples of how common vulnerabilities like SQL injection, XSS, and session hijacking could be detected. It recommends a tiered approach to IDS with different levels of logging, alerting, and blocking of suspicious traffic.
This document discusses using intrusion detection systems (IDS) to monitor web applications for security threats. It explains that IDS can be used to detect both known and unknown attacks. A positive security model uses whitelists to allow only known good traffic, but this has limitations for complex data types. A negative security model uses blacklists of known attack patterns, but cannot detect all unknown attacks. The document advocates a tiered approach to security logging and monitoring with increasing levels of detail and prioritization of alerts.
This document discusses using intrusion detection systems (IDS) to monitor web applications for security threats. It explains that IDS can be used to detect both known and unknown attacks by logging all activity and applying both whitelist and blacklist rules. The document also provides examples of how different types of attacks could be detected, such as SQL injection, cross-site scripting, and session hijacking. It recommends a three-tiered approach to IDS that involves logging all activity, detailed logging of detected attacks, and flagging possible intrusions for manual review.
This document discusses using intrusion detection systems (IDS) to monitor web applications for security threats. It explains that IDS can be used to detect both known and unknown attacks by logging all activity and applying both whitelist and blacklist rules. The document also provides examples of how different types of attacks could be detected, such as SQL injection, cross-site scripting, and session hijacking. It recommends a three-tiered approach to IDS that involves logging all activity, detailed logging of detected attacks, and flagging possible intrusions for manual review.
In this presentation, you can learn many practical resources about WAF, how you can create your WAF, and how you can bypass protections in common WAFs.
This document discusses various application security topics such as downloading files securely, handling secrets and temporary tokens, implementing third-party sites securely, privacy risks of third-party monitoring and analytics on sensitive pages, push notifications versus SMS, securely using FFmpeg and ImageMagick, serving user content securely, implementing cryptography securely, and applying rate limits. It provides advice on how to address each topic securely, such as only allowing certain schemes, ports and domains for file downloads, short expiration times for temporary tokens, sandboxing or isolating third-party components, and not implementing one's own crypto.
This document discusses various web application security vulnerabilities and methods for mitigating them. It begins by summarizing the OWASP Top 10 list of most critical web application security risks. It then provides examples of different types of injection attacks, cross-site scripting, broken authentication and session management issues. The document also discusses insecure cryptographic storage, insufficient transport layer protection and other vulnerabilities. It emphasizes the importance of input and output validation, as well as proper encoding to prevent attacks. The OWASP ESAPI framework is presented as a tool to help developers address many of these security issues.
Secure Android development involves understanding attack vectors, attack surfaces, and best security practices. The document outlines various attack vectors like buffer overflows and privilege escalation. It describes attack surfaces like the browser, system, phone/SMS, apps, and external networks. It recommends avoiding simple logic, testing third-party libraries, implementing anti-tamper techniques, securely storing sensitive data in RAM, and understanding secure deletion of data. Understanding these concepts is key to developing securely on Android.
This document discusses various security issues that can arise in source control systems. It describes buffer overflow attacks, where a program writes data past the end of a memory buffer. It also discusses citizen/casual programmers who may not follow proper security practices. Covert channels that can transfer data in violation of security policies are described. The document outlines controls and best practices around these issues like parameter checking, memory protection, and auditing and logging.
APIsecure 2023 - API Security - doing more with less, Nir Paz (Standard.ai)apidays
APIsecure 2023 - The world's first and only API security conference
March 14 & 15, 2023
API Security - doing more with less.
Nir Paz, Product Management at Standard.ai
------
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/
This gives insight on how people manipulate online servers to do harm, *without* exposing security risks.This simply explains whats going on during this activity and how to protect yourself.
Application Security - Your Success Depends on itWSO2
Traditional information security mainly revolves around network and operating system (OS) level protection. Regardless of the level of security guarding those aspects, the system can be penetrated and the entire deployment can be brought down if your application's security isn't taken into serious consideration. Information security should ideally start at the application level, before network and OS level security is ensured. To achieve this, security needs to be integrated into the application at the software development phase.
In this session, Dulanja will discuss the following:
The importance of application security - why network and OS security is insufficient.
Challenges in securing your application.
Making security part of the development lifecycle.
The document provides guidelines for secure coding. It discusses the evolution of software markets and increased security threats. Common web attacks like injection, broken authentication, and sensitive data exposure are explained. The OWASP Top 10 list of vulnerabilities is reviewed. The document emphasizes the importance of secure coding practices like input validation, output encoding, and using components with no known vulnerabilities. Following a secure coding lifestyle can help developers write more secure code and protect against attacks.
This document provides an agenda for a web application penetration testing course. The course aims to share cybersecurity knowledge in Arabic and focus on practical application. It will cover Linux basics, Burp Suite, common web vulnerabilities at easy and medium levels, and advanced topics like XSS and CSRF. Students will learn how to find data leaks, analyze protocols and network traffic, exploit vulnerabilities, and earn money through bug bounty programs.
Web application scanners crawl a web application to locate vulnerabilities by simulating attacks. They work by supporting various protocols, crawling and parsing content, testing for vulnerabilities, and generating reports. While scanners help find issues, developers should focus on learning secure coding practices to build applications securely from the start.
Web Security: What's wrong, and how the bad guys can break your websiteAndrew Sorensen
1. The document summarizes a presentation on web security given to the Seattle PHP Users Group. It discusses common web vulnerabilities like SQL injection, cross-site scripting, and insecure direct object references.
2. It provides tips for protecting websites such as implementing a web application firewall, securing file permissions, and using HTML5 features like Content Security Policy headers.
3. The presentation emphasizes that security is an ongoing process of monitoring for updates, testing with hacking tools, and seeking outside reviews of a site's security.
The document summarizes key points about web application security vulnerabilities and how to address them. It discusses common vulnerabilities like parameter manipulation, cross-site scripting, and SQL injection that occur due to improper validation of user input. It emphasizes the importance of validating all user input on the server-side to prevent attacks, and not storing sensitive values in cookies or hidden form fields that can be manipulated by attackers.
OWASP Top 10 vs Drupal - OWASP Benelux 2012ZIONSECURITY
The document discusses securing Drupal against the OWASP Top 10 vulnerabilities. It provides examples of how vulnerabilities like SQL injection, XSS, session hijacking, insecure direct object references, CSRF, misconfiguration issues and failure to restrict URL access could occur in Drupal. It also explains the security measures Drupal has implemented, such as input filtering, form tokens, access control and encryption to address these risks.
This document discusses using intrusion detection systems (IDS) to monitor web applications for security threats. It explains that IDS can be used to detect both known and unknown attacks by logging all activity and applying both whitelist and blacklist rules. The document also provides examples of how common vulnerabilities like SQL injection, XSS, and session hijacking could be detected. It recommends a tiered approach to IDS with different levels of logging, alerting, and blocking of suspicious traffic.
This document discusses using intrusion detection systems (IDS) to monitor web applications for security threats. It explains that IDS can be used to detect both known and unknown attacks. A positive security model uses whitelists to allow only known good traffic, but this has limitations for complex data types. A negative security model uses blacklists of known attack patterns, but cannot detect all unknown attacks. The document advocates a tiered approach to IDS that involves logging all activity, providing detailed logs of detected attacks, and generating high-priority alerts for possible intrusions.
This document discusses using intrusion detection systems (IDS) to monitor web applications for security threats. It explains that IDS can be used to detect both known and unknown attacks. A positive security model uses whitelists to allow only known good traffic while a negative model uses blacklists to detect malicious patterns. The document then examines how different types of attacks from the OWASP Top 10 could be detected, such as XSS, SQL injection, and session hijacking. It advocates a three-tiered approach to security monitoring with different levels of logging and alerting.
This document discusses using intrusion detection systems (IDS) to monitor web applications for security threats. It explains that IDS can be used to detect both known and unknown attacks by logging all activity and applying both whitelist and blacklist rules. The document also provides examples of how common vulnerabilities like SQL injection, XSS, and session hijacking could be detected. It recommends a tiered approach to IDS with different levels of logging, alerting, and blocking of suspicious traffic.
This document discusses using intrusion detection systems (IDS) to monitor web applications for security threats. It explains that IDS can be used to detect both known and unknown attacks by logging all activity and applying both whitelist and blacklist rules. The document also provides examples of how common vulnerabilities like SQL injection, XSS, and session hijacking could be detected. It recommends a tiered approach to IDS with different levels of logging, alerting, and blocking of suspicious traffic.
This document discusses using intrusion detection systems (IDS) to monitor web applications for security threats. It explains that IDS can be used to detect both known and unknown attacks. A positive security model uses whitelists to allow only known good traffic while a negative model uses blacklists to detect malicious patterns. The document then examines how different types of attacks from the OWASP Top 10 could be detected, such as XSS, SQL injection, and session hijacking. It advocates a three-tiered approach to security monitoring with different levels of logging and alerting.
This document discusses using intrusion detection systems (IDS) to monitor web applications for security threats. It explains that IDS can be used to detect both known and unknown attacks by logging all activity and applying both whitelist and blacklist rules. The document also provides examples of how different types of attacks could be detected, such as SQL injection, cross-site scripting, and session hijacking. It recommends a three-tiered approach to IDS that involves logging all activity, detailed logging of detected attacks, and flagging possible intrusions for manual review.
This document discusses using intrusion detection systems (IDS) to monitor web applications for security threats. It explains that IDS can be used to detect both known and unknown attacks. A positive security model uses whitelists to allow only known good traffic while a negative model uses blacklists to detect malicious patterns. The document then examines how different types of attacks from the OWASP Top 10 could be detected, such as cross-site scripting, SQL injection, and session hijacking. It recommends a three-tiered approach to security monitoring that involves logging all activity, detailed logs of attacks, and alerts of possible intrusions.
This document discusses using intrusion detection systems (IDS) to monitor web applications for security threats. It explains that IDS can be used to detect both known and unknown attacks by logging all activity and applying both whitelist and blacklist rules. The document also provides examples of how different types of attacks could be detected, such as SQL injection, cross-site scripting, and session hijacking. It recommends a three-tiered approach to IDS that involves logging all activity, detailed logging of detected attacks, and flagging possible intrusions for manual review.
This document discusses using intrusion detection systems (IDS) to monitor web applications for security threats. It explains that IDS can be used to detect both known and unknown attacks by logging all activity and applying both whitelist and blacklist rules. The document also provides examples of how common vulnerabilities like SQL injection, XSS, and session hijacking could be detected. It recommends a tiered approach to IDS with different levels of logging and alerting to balance security and manageability.
O documento descreve as etapas de desenvolvimento de um projeto. Ele discute a situação inicial, mudanças significativas como alterações de tecnologia e nome, o que foi feito incluindo banco de dados, wireframes e Gantt chart, dificuldades enfrentadas como problemas com ferramentas e APIs, e a menção a um protótipo.
3. Reasons for using
IDS solutions
● known weaknesses and vulnerabilities
● balance between security and usability
rd
●
3 -party applications and libraries
● insecure client software
● additional layer of security
● fear, uncertainty, doubt
IDS, IPS or WAF?
4. IDS purpose
● data source for post-intrusion analysis
● real-time intrusion investigation
● holy grail: intrusion prevention
How can we detect unknown attacks?
5. Positive security model
● “accept known good” mantra
● allowed byte ranges
● regular expressions
● allowed variables whitelist
What about encoded (base64, weak encryption,
multiple charsets) or complex (HTML, file
upload) data?
6. Positive security model
● when application changes, whitelist has to
change too
● lots of alerts
● http://p1.tld/p2/p3.php/p4/p5=p6,p7?p8&p9=p0
● real-time protection? block them all!
● sanitizing wrong input could help
Why can't we do this in the application itself?
7. It's easier to fix applications,
than detect attacks
● usually true
●
3rd party software and libraries
● unknown attack methods
● security filters adding new vulnerabilities
● example: HTML filters
8. HTML filters review – March
2008
Tested: 5 popular anti-XSS HTML filters (PHP)
Results:
● 3/5 vulnerable to XSS (+1 already known 0-day)
● 2/5 included PHP code execution bugs (kses,
htmLawed)
● alternative syntax like Textile or Markdown also
not safe from XSS
9. Negative security model
● blacklist detection rules
● far less alerts
● classification by attack type, priority, etc.
● generic rules: often too general, false positives
● specific rules: very limited, often outdated
How to detect unknown attacks?
10. Examples
● Snort – known exploits
● ModSecurity Core Rules – generic
● PHPIDS – generic, focused on XSS
11. PHPIDS
● LGPL licensed IDS library for PHP applications
● impact rating for each malicious request
● could be added in auto_prepend_file, without
modifying application code
● attempts to detect unknown attack patterns
http://php-ids.org/
13. What are we trying to detect?
● automated exploits
● automated vulnerability scanners
● manual attacks
● uncommon user behaviour
● intrusion vs vulnerability testing
How to recognize source type?
14. A1 - Cross Site Scripting (XSS)
● most common: <script, document.cookie
● dangerous HTML tags and attributes
● breaking out of HTML attribute
● JavaScript keywords
● comparing request and response
● PHPIDS regular expressions
15. XSS from attacker's view
● needs just one byte to detect vulnerability,
e.g. “, <, (
● easy to make it look innocent
<a href=”http://tested.site.tld/page.php?
id=article">Interesting article</a>
<script>[Google Analytics]...
● usually needs at least several requests to
prepare working attack (for custom application)
16. XSS – detection
● hard to detect less common vulnerability testing
patterns
● recognizing malicious XSS code is easier
● time window between finding vulnerability and
developing exploit
● real-time detection could prevent attack
rd
How to detect DOM-based XSS or 3 party
JavaScript/CSS modifications?
17. XSS – reducing false positives
● different rules for public and private application
sections
● check for persistent XSS after HTML filtering
(response buffering or PHPIDS)
● don't alert when only single keyword/char
matches rule (skip non-malicious XSS)
● raise impact rating for suspicious or missing
Referer headers
● don't even think about “trusted IPs”
18. A2 – Injection Flaws
● paranoid mode: blocking semicolon and quotes
● checking for SQL (or other language) keywords
● 2.0, 2-0, 2-1, 2;[query]
● val'||', val';[query]
● 2 AND 1=1, 2 AND 1=2
● 2 UNION...SELECT [query]
● /*...*/, /*!...*/
● “page.tld/page?var=1/*&UNION SELECT*/”
19. SQL Injection
● relatively easy to detect malicious attacks
● many false positives, if we want to detect
vulnerability testing
● good results with whitelisting
● reducing false positives by checking traffic
between application and database (or in the
application, before executing query)
● real-time reporting of SQL query errors
20. Command/Code Injection
● much wider range of malicious code than for
SQL Injection
● detect vulnerability testing, not exploits
● reducing false positives by eliminating known
vectors
● common commands and functions
● `, {${, <?, <%
● real-time reporting of application errors
23. A4 – Insecure
Direct Object Reference
● easier to fix than detect
● whitelisting often doesn't help
● we can try to detect data harvesting tools
● multiple requests to the same page, with
different set of parameters
● repeating requests to a single page or a small
subset of pages
● small mistakes in automatically generated
requests (Referer, null bytes, missing headers
or cookies)
24. A5 – Cross Site Request Forgery
(CSRF)
● why black hats love CSRF?
● again, it's really easier to fix than detect
● external or missing Referer header
● missing cookies
● Accept header
● user trying to perform action while logged out
● user trying to remind password while logged in
● broken application flow
● Referer-less redirects, clickjacking
25. A6 – Information Leakage and
Improper Error Handling
● monitoring outbound traffic (e.g. ModSecurity)
● application code, HTML comments, error
messages (esp. SQL)
rd
●
3 party software may leak undocumented or
non-standard error messages
● what information should be treated as leakage
(and how IDS knows it)?
● Blind SQL Injection
26. Forcing errors
● var[]=1
● 1.1, 1x, ./1, /1
● “, ', !, %0A, %00
● wrong type of data
● wrong format of session identifier
● DoS
● ...
● too many possibilities to check requests
27. A7 – Broken Authentication and
Session Management
Session hijacking detection
● another one that is easier to fix in the
application itself (or rather “fix”)
After identifier is stolen:
● IP address change during session
● headers changed/missing during session
Before:
● tampering session identifiers
● XSS
28. Session hijacking
– attacker's view
● sniffing traffic
Spoof IP, everything else you already have.
● XSS
You don't need to hijack session identifier,
just force the victim to do whatever you
wanted.
● Referer header
29. A8/A9 – Insecure Cryptographic
Storage and Communications
● not much to do for an IDS
(at least on the server side)
● passing base64-encoded or weakly encrypted
values to the client
● WAF protection against tampering
● may be decrypted on client side and leak
information
● general brute-force attacks detection
30. A10 – Failure to Restrict URL
Access
● IDS has no information about user rights in the
application
● known vulnerabilities in libraries/include files
● brute-force detection may deal with fuzzing
● broken application flow
● whitelisting
● IPS/WAF as a hotfix solution
32. Log, block, alert
3-tier solution
Tier 1:
● log everything you can
Tier 2:
● detailed log of detected attack attempts
Tier 3:
● possible intrusions and bypasses
33. Tier 1
● log everything you can
● all application errors
(with their context)
● full requests
(URL, headers, cookies, body)
● full responses
(HTTP code, headers, body)
34. Tier 2
● detailed log of detected attack attempts
● IDS alerts
● combined data from several sources
● including vulnerability testing patterns
● including blocked/sanitized requests
● optionally: requests following blocked one
35. Tier 3
● possible intrusions and bypasses
● alerts that require manual verification
● generate as much as you are able to check
manually
● skip blocked requests