OWASP EU Summit 2008 Training
EU Summit 2008 Trainings
cevent links to be added.
- 1 Web server/services hardening using SELinux
- 2 Secure Programming with Java
- 3 OWASP Top 10 - What Developers Should Know on Web Application Security
- 4 Linux Software Exploitation
- 5 Classic ASP Security using OWASP tools
- 6 Web Application Assessments
- 7 Hacking Owasp Orizon Project v1.0
- 8 Securing WebGoat with ModSecurity
Web server/services hardening using SELinux
Security-Enhanced Linux (SELinux) is a FLASK implementation integrated in the Linux kernel with a number of utilities designed to provide mandatory access controls (MAC) through the use of Linux Security Modules (LSM) in the Linux kernel. SELinux generally supports many kinds of mandatory access control policies, including those based on the concepts of type enforcement, role-based access control, and multi-level security.
A Linux kernel integrating SELinux enforces mandatory access control policies that confine user programs and system servers to the minimum amount of privilege they require to do their jobs. This reduces or eliminates the ability of these programs and daemons to cause harm when compromised (via buffer overflows or misconfigurations, for example). This confinement mechanism operates independently of the traditional Linux access control mechanisms. It has no concept of a "root" super-user, and does not share the well-known shortcomings of the traditional Linux security mechanisms (such as a dependence on setuid/setgid binaries).
This training provides basic concepts of SELinux, its differences to classical UNIX/Linux systems, describe security advantages of mandatory access control policies and teach how to effectively and rapidly configure a fully functional LAMP environment on SELinux system.
Security consultants, system administators, programmers focused on system security
Table of Contents
1. SELinux history
2. Unix/Linux DAC (Discretionary Access Control) and its problems
3. MAC (Mandatory Access Control)
4. Advantages of using MAC
5. DTE (Domain Type Enforcement) model
6. RBAC (Roles Based Access Control) model
7. MLS (Multi Level Security) model
8. SELinux FLASK Architecture
9. SELinux policy (EXERCISE)
10. File System Security Contexts (EXERCISE)
11. SELinux Object Classes and Permissions
12. TE (Type Enforcement) Rules (Attributes, Type Declaration, Type Transitions, Domain Type Transitions, Object Labeling Transitions, Access Vectors)
13. Understanding AVC, log messages
14. audit2allow and audit2why (EXERCISE)
15. SELinux Troubleshoot Tool (EXERCISE)
16. Auditing and Auditing tools
17. Policy Macros
18. Backtracking rule (EXERCISE)
19. SELinux Users, Roles, MLS Levels
20. Strict Policy
21. Targeted Policy
22. SELinux Booleans and their use for Apache web server (EXERCISE)
23. Files and Directories in Targeted Policy, common SELinux Macros (EXERCISE)
24. Analyzing Example Policy - apache.te (EXERCISE)
25. Assigning Object and Process Types
26. SELinux Booting
27. Copying and moving files, checking security contexts, relabeling a file and directory's security context (EXERCISE)
28. Policy core utilities
29. Managing File Labeling, Relabeling a File System (EXERCISE)
30. SELinux Administrator GUI (EXERCISE)
31. SELinux Modules (EXERCISE)
32. Hardening existing LAMP environments using SELinux (EXERCISE)
33. Writing New Policy for a Daemon (EXERCISE for clever students)
Bring your own laptop. Each student will have own SELinux virtual machine for his experiments.
Secure Programming with Java
Lucas C. Ferreira
This training class will present best practices of secure programming in the Java language. It includes Java specific practices (i.e. how to avoid problems that arise from the compilation of Java source code to the bytecode language used by the JVM) and practices that may arise in other programming languages (with examples in Java). Some tools that may be used to verify the security of Java code and systems will be shown.
The topics include a quick overview of the OWASP Top 10, in order to contextualize the practices presented, and several best practices aimed at the different software layers. At the presentation layer, we focus on input validation, access control issues and dealing with exceptions. At the business objects layer, the practices deal with cloning and serialization issues. Practices to prevent command injection are presented at the persistence layer. Practices that should be used throughout all the software are also presented, including input data validation, class and method visibility, using and storing secrets, dealing with inner classes, overflows and boxing, and object initialization.
Java web application developers. This training requires basic understanding of web applications and an intermediate level of proficiency in the Java language and Object Oriented concepts. People with interest in other OO languages may also benefit from this training, but specific techniques, examples and tools used are targeted to Java.
Table of Contents
- OWASP Top 10 - quick overview
- Secure Programming Best Practices
- Presentation layer
- Preventing cross-site scripting
- Access control
- Request validation
- Error treatment
- Business object layer
- Cloning and serialization issues
- Persistence layer
- Command injection issues
- Database access users and permissions
- file manipulation
- Infra-structure layer
- J2EE container-related best practices
- Native method issues
- SSL and encryption
- Practices for all software layers
- Data validation
- Garbage collection issues
- Classes and method scoping
- Use of secrets
- Inner class issues
- Over/underflow and boxing issues
- Presentation layer
- Code review tool
- Data flow tool
- Pen-testing tool
Due to the lack of time, we will only show tool usage (no practical exercises with the audience).
OWASP Top 10 - What Developers Should Know on Web Application Security
Sebastien Deleersnyder and Martin Knobloch
4 h To be scheduled on Wednesday morning + afternoon Nov 5.
Application security is an essential component of any successful project; this includes web applications, open source PHP applications, web services and proprietary business web sites. Web application security education and awareness is needed throughout the entire development and deployment organization. Each area and level of development or deployment organizations have specific needs and requirements regarding web application security education. A manager needs other information than a security professional or developer. Novices to the profession require other training than people with several years of experience.
The OWASP Education project aims to provide in building blocks of web application security information. These modules can be combined together in education tracks targeting different audiences. This Education Track provides in a 4 hour session covering what developers should know on web application security. It starts with an explanation of web application security and why it is important. Then the OWASP Top 10 is used to explain the nastiest vulnerabilities and how these can be prevented or re mediated. A secure coding initiative must deal with all stages of a program’s life cycle. Secure web applications are only possible when a secure SDLC is used. The SDLC is explained from the standpoint of people, processes and tools. Particularly for developers good secure development practices are covered in a separate topic. Finally the track finishes with an exhaustive list of web application security resources for web application developers.
Web application developers who are unaware there are security issues with contemporary web applications. No prior knowledge of web application security is assumed nor necessary. This track is independent of the coding language or web frameworks used; like PHP, JSF, Java EE or .NET. We must realize that web application developers are only one link - albeit an important one - of the chain that represents the security of a web application. This track aims to make that link as secure as possible, given the constraint of 4 hours. Another important aspect is that web application security should be tailored to the risk profile of an organization and the specific development environment of that organization.
Table of Contents
The challenge is to cover web application security in 4 hours to a web application developer. This is presented in such a way that the developers will be able to recognize and correct web application vulnerabilities in their projects.
- This part is the introduction of the track. It identifies the current security problems with web applications. During the introduction a definition of web application security is given. Trends that are influencing the current state of web application insecurity are also explained.
- What goes wrong
- WebAppSec Defined
- Current trends
- The primary aim of the OWASP Top 10 is to educate developers, designers, architects and organizations about the consequences of the most common web application security vulnerabilities. The Top 10 provides basic methods to protect against these vulnerabilities.
- Cross Site Scripting (XSS)
- Injection Flaws
- Malicious File Execution
- Insecure Direct Object Reference
- Cross Site Request Forgery (CSRF)
- Information Leakage and Improper Error Handling
- Broken Authentication and Session Management
- Insecure Cryptographic Storage
- Insecure Communications
- Failure to Restrict URL Access
- There is no silver bullet when it comes to securing web applications. This problem has to be addressed from different angles, covering the involved actors, processes: development as well as deployment and Technologies.
- People Awareness and Education
- Development WebAppSec Controls
- Deployment WebAppSec Controls
- WebAppSec Tools
- Next to the Top 10 remedies this module provides some good secure development practices from the OWASP Guide, covering e.g.
- Validating User Input
- Session Management
- Using Interpreters
- Catching Errors
- File System
- Web 2.0
- One important aspect is to test for application vulnerabilities. During this short module an introduction is provided together with some WebGoat test cases.
- Testing for application vulnerabilities
- The OWASP Testing Guide
- WebGoat demonstrated
- This 4 hour education track in only the beginning of your journey. Web application security is a moving target. New vulnerabilities and threats are discovered regularly. Web application security controls are becoming mature. The following resources should provide you with enough pointers to serve both as reference and for further research.
- Hard Copy
- Web Sites
- Mailing lists
- Roundup (10 min)
No specific prerequisites.
Linux Software Exploitation
This course is a primer into software exploitation on the Linux environment. The course assumes only basic understanding of the Linux commands, and C programming with the standard library. It explains the computer architecture, assembly language then moves on to three basic classes of security bug: buffer overflow, format string, and race condition and methods to take advantage of them. Throughout the course, various examples are introduced with increasing difficulty so that participants will naturally realize the art of software exploitation for themselves.
This course does not discuss about shell coding. Except on one example where provided shell code is used as an illustration, all other challenges require only good analysis and calculation.
The course is conducted as a workshop with heavy interaction between participants and instructor. There will not be any presentation slide. Participants are to take note during the course.
Software developers, system administrators, security engineers with some experience in Linux and C programming.
Table of Contents
- Computer architecture
- Assembly language
- Buffer overflow
- Format string
- Race condition
- Overwrite critical variable
- Overwrite return address
- Return to .text
- Return to libc
- Overwrite .dtors
- Overwrite .got
- Overwrite .bss, functors
- By pass Advanced Space Layout Randomization
- Tools of the trade: IDA, GDB, and Python
Bring your own laptop with VMWare Player or equivalent. An VM image will be provided.
Classic ASP Security using OWASP tools
Juan Carlos Calderon
Classic ASP 2.0 and 3.0 applications are still largely used as this technology is more than 10 years old and was largely used. there are thousands of sites on the wild that need guidance on the security arena. This is where OWASP can come up and provide help for “making the Web a better place”.
Classic ASP Developers, Application Architects, people with basic ASP knowledge?
Table of Contents
- Secure programming on ASP using OWASP ESAPI
- Auditing ASP code with Code Review Project checklist
- Implementing OWASP Stinger protection for Classic ASP
- ASP specific Best Practices to protect ASP applications.
None. Keep posted for changes on the table of contents and course specifics.
Web Application Assessments
Vicente Aguilera Diaz
As in the physical world, the "professionals" attackers spend most of their time to analysing its objective and try to gather as much information as possible about it. The more information becomes available and is more detailed and accurate, the attack is more likely to succeed.
The aim of this course is to identify patterns and tools to perform this analysis (step prior to the attack), and is supplemented by a case study on a practical application.
Software developers, security consultants, system administrators and people loving security.
Table of Contents
- Web Application Discovery
- Gathering information on the target web application
- Search Engines
- Interaction with external entities and information services
- Analysis of existing information in the web application (public information, information leaks, causing errors, etc.).
- Knowing / Understand the target
- Identifying characteristics (technologies, platforms, user profiles, features, etc.).
- Analysis of infrastructure components: databases, Web servers, application servers, authentication servers, etc.). Detection and identification.
- Identification of the exposition area
- Analysis of attack vectors and vulnerabilities exploitation
- Case Study
- Assessment of an webmail application
- Vulnerability exploitation: IMAP / SMTP Injection
Bring your own laptop.
Hacking Owasp Orizon Project v1.0
In the course it will be presented Owasp Orizon v1.0 framework. The major APIs will be fully explained and it will be built a simple scanning tool using the Orizon framework.
The course goal is to let people fully understand Orizon internals and let people understand how to use the framework in a real world.
Security specialist, code reviewers and curious developers
Table of Contents
- Owasp Orizon Internals
- Translation engine
- Owasp Orizon XML project
- XML used in writing security checks
- XML used in translation phase
- Static analysis engine
- Crawling engine
- Reporting engine
- Create a simple tool using Orizon
People have to bring their own laptop with latest Owasp Orizon version, J2SE 1.6 or later and a Java IDE (e.g. eclipse) is also feasible.
Securing WebGoat with ModSecurity
Stephen Craig Evans
ModSecurity, normally a tool of the network security group, has capabilities that can allow a software security specialist with programming skills to mitigate business logic flaws and other vulnerabilities that are out-of-reach of basic blacklists.
This 4 hour course covers the highlights of the Summer of Code 2008 project, "Securing WebGoat using ModSecurity" (please see https://www.owasp.org/index.php/Category:OWASP_Securing_WebGoat_using_ModSecurity_Project and the project wiki).
- Users of ModSecurity that want to learn how it can be leveraged beyond the basic rule sets in order to mitigate vulnerabilities in areas such as authentication, AJAX, and output sanitization
- Web application specialists, especially pentesters, who want to learn how ModSecurity can offer an additional remedial solution to customers when the application cannot be touched
- Curious people that are wondering what the hell this project is about
Table of Contents
- ModSecurity basics
- WebGoat overview
- A walkthrough of the "Securing WebGoat using ModSecurity" Summer of Code 2008 project
- Mitigating WebGoat vulnerabilities using the ModSecurity core rule set
- Using ModSecurity's Lua scripting language:
- For its programming capabilities (including re-building the Lua library to include 3rd party functionality)
- To implement configuration files
- For global persistence
- And much, much, more...
- To enhance the user experience when implementing a ModSecurity solution on the back end such as an authentication mechanism
Demos (including strategy and implementation) of the most interesting lesson solutions will be shown.