Next 6th November we will have the next OWASP-Italy Day.
In this occasion CIOs, CTOs, CISOs, Auditors, IT managers, Security Managers and Security Governance managers, will have the opportunity to uptade about the evolution about the Application Security and the new intiatives about Software Security.
The Agenda:
9:00h Registration
9.30h Introduction to the OWASP-Day
Matteo Meucci - OWASP-Italy Chair
9.50h How to Create Business cases for Your Software Security Initiative
Marco Morana — CISO, Citigroup
10.30 OWASP SAMM / Open Software Assurance Maturity Model
Claudio Merloni — Software Security Consultant, Fortify Software
11.10h Coffee break
11.40h From Web Attacks to Malware. Can Secure Software Development Help Internet Banking Security?
Giorgio Fedon — COO, Minded Security
12.20h Usability versus security: securing Internet facing applications while keeping them highly attractive for everybody
Tobias Christen — CTO, DSwiss Ltd
13.00h Business Lunch
14.00h NoScript, CSP and ABE: When the Browser Is Not Your Enemy
Giorgio Maone — CTO, InformAction
14.40h Building Security In Maturity Model: A Review of Successful Software
Gabriele Giuseppini — Technical Manager, Cigital
15.20h The art of code reviewing
Paolo Perego — Senior Consultant, Spike Reply
16.00h Round Table: Why Software Security is not a priority in our digital world?
Marco Morana, Carlo Merloni, Gabriele Giuseppini, Stefano Di Paola — Keynote Raoul Chiesa
References:
"Avete finito di imbottire le vostre reti di firewall e altre diavolerie simili? Allora è tempo di cambiare prospettiva e rendersi conto che oggi, dopo aver messo in sicurezza il perimetro dei nostri sistemi informativi, le minacce più serie provengono dalle nostre stesse applicazioni che, a volte, non sono progettate ed implementate, tenendo conto delle migliori pratiche di sviluppo di software sicuro. In questo campo l’OWASP rappresenta un punto di riferimento costante ed una miniera di informazioni e strumenti, ed al Ministero dell’Istruzione, Università e Ricerca abbiamo imparato ad apprezzarne i materiali e le informazioni disponibili sul suo sito web, nell’ambito del nostro gruppo che si occupa di sicurezza del sistema informativo. Per conoscere le iniziative dell’OWASP, avere un’anteprima delle principali novità in tema di sicurezza del software, incontrare i maggiori esperti in questo settore, partecipate all’OWASP DAY – ITALY IV il 6 novembre prossimo a Milano, sarà un’occasione utilissima di approfondimento."
Paolo De Santis – Dirigente della Direzione Generale per gli Studi, la Statistica ed i Sistemi Informativi del MIUR
“L’OWASP Day è il luogo e il momento per incontrare altri professionisti e appassionati del settore. E’ un’opportunità per conoscere direttamente dai protagonisti le metodologie, le tecniche e gli ambiti di ricerca nel mondo della sicurezza applicativa divenuto ormai il fattore principale, insieme a quello umano, nel campo dell’Information Security. “
Massimo Trevisani—CSO IWBank
"Le conferenze OWASP in Italia rappresentano un momento importante di awareness sulla sicurezza applicativa. L'evento rappresenta un punto di riferimento in cui i professionisti dell'IT possono valutare nuovi approcci allo sviluppo sicuro del software e alla difesa delle proprie applicazioni on-line"
Marco Bavazzano—CISO Telecom Italia
More information and registration to the event
here
Sunday, October 11, 2009
Thursday, May 21, 2009
HTTP Parameter Pollution FAQs
We have received numerous public replies as well as several private emails.
Thanks for your comments, suggestions and feedbacks.
It's now time to summarize and clarify some points.
Q: Is this a new class of exploits or just another case of applications lacking input validation?
A: Actually, HPP is an input validation flaw. As SQL Injection and XSS, we may consider it as an injection weakness.
In this specific case, query string delimiters are the "dangerous" characters.
Q: You are saying that several HTTP back-ends manage multiple occurrences in different ways. In some cases, it may be abused in order to fingerprint the underline back-end. Is it right?
A: Yes, sure. However, considering the granularity available, we don't think it is really so interesting.
Q: This is a known attack. You guys presented a bunch of interesting but already known techniques to exploit different vulnerabilities.
A: Actually, we think we have contributed (in some way) to the current state-of-art showing this issue. However, even if it is currently used by 'hard-core' attackers, it's very important to formalize a threat in order to mitigate the issue and create efficient workarounds.
The aim of the entire research is to raise awareness around this problem.
In future, we would like to include HPP within the OWASP Testing Guide in order to provide the right methodology for testing systems against HPP-like attacks as well.
We strongly believe that sharing such knowledge may increase the security of all web applications.
Q: Most of your examples and findings use GET parameters. What about POST?
A: POST and COOKIE parameters may be affected as well. In slide #11 and #19, we have briefly stated that and you will see further research because it is a very interesting aspect since it gives additional flexibility for all attacks.
Q: In the current version of IE8, is the XSS Filter still vulnerable to HPP?
A: No! We had a discussion with the IE XSS Filter guy at Microsoft and turns out that the current version is NOT affected. All previous tests were done against the beta release and we didn't double check the latest one. We are sorry for this misunderstanding.
Q: Are multiple occurrences of a parameter valid according to the RFC, W3C, whatever?
A: Yes! Yes! The only thing which in fact was worth mentioning is the lack of standard in the _management_ of multiple occurrences and NOT the presence of multiple occurrences themselves.
After all, that's why it is possible to abuse the query string delimiters injection flaw.
Q: Is Yahoo! Mail still vulnerable to HPP?
A: Difficult to say. However, the specific issue was patched thus it cannot be abused by malicious users.
Q: Could you provide additional details regarding the Yahoo! Classic Mail HPP attack?
A: We've just published here an in-depth review of the issue with the video PoC as well.
Q: What's the right way of managing multiple occurrences? Is there a 'perfect' framework?
A: No, there are no right o wrong behaviors as well as we cannot refer to a right or wrong web servers/web frameworks. The behavior of the HTTP back-ends is a matter of exploitability, only.
Q: HPP is only about WAFs bypasses?
A: Absolutely not! HPP is also about applications flow manipulation, anti-CSRF, content pollution.
Q: How can I prevent HPP?
A: First of all, answer yourself "Which layer am I protecting?".
Then, speaking about HPP server side, it's always important to use URL encoding whenever you do GET/POST HTTP requests to an HTTP back-end.
From the client-side point of view, use URL encoding whenever you are going to include user-supplied content within links, etc.
Q: Am I vulnerable to HPP?
A: It depends on how you are managing several occurrences of the same parameter from the application point of view. Using strict input validation checkpoints and the right output filtering (URL encoding), you are likely secure (at least, against HPP :p).
That's all (for now).
Discretionary controls may lead to social engineering attacks against banking dongles
New social engineering attack strategies will deal with the fact that some details entered in banking transactions are checked discretionally by the receiving institute. Any bank has a different database for user details and a different policy: that’s good because user details are kept very confidentially. However any single institute has very proprietary controls; some do well, some do not.
The bad news is that one misbehaving entity is enough for lowering the security of the network. Attacker could choose the only bank in the country that has very weak controls, since the goal is to receive banking transfers from other people.
Let's assume that the bank where Mallory has his account will accept bank transfers if the the recipient is wrong and the amount transferred is lower than 5k. We could have a situation like the following one:
What If your bank will receive the correct account number with a wrong name on it? Well, the correct Beneficiary Name is not mandatory for issuing a bank transfer, but your bank (the receiving party) could accept it or not.
Usually the attacker has still 3 additional days to phone the receiving bank and try to persuade one employee to finalize the transaction before the transfer gets blocked.
We did some tests about sending money in our country to correct IBAN account numbers, but to wrong recipients.
Some results:
Attackers may take advantage of these issues to perform social-engineering attacks directly on antimalware devices.
Effective attack strategy could be once again luring the user into confirming the wrong transaction, by preserving those fields that are actually remembered by the user. So which fields can be easily remembered?
The main challenge in designing Antimalware solutions is to “Authenticate the Transactions to the user”. The most common way to meet this requirement is to provide an out of band channel that displays the transaction details in a secure manner. In this way the user can spot if “something” between him and the bank has interfered within the transmission.
Typical attacks against banking security solutions are impersonation attacks that need a malware already installed on the user system. The following is an example of a very common MITM (Man in the Middle Attack) performed on the local user machine:
By giving a clarifying example, let’s assume that the user (Bob) is doing a banking transfer to his friend (Alice). The details displayed out of band on the external devices will be:
Amount of Transaction: 300
Recipient: Alice
Country: Wonderland
IBAN: WL04292039280100000000918292
If an attacker using a malware capable of “Local Man in the Middle Attack” changes some of the details, the external devices will prompt for confirmation. At this point the transaction will look very different from the original one:
Amount of Transaction: 10000
Recipient: Mallory
Country: Wonderland
The IBAN: WL053510393501200000003523491
This fraud attempt is easy to spot, even if the attacker is using a mule in the same country as the victim: Transaction Amount and Recipient Details are very different from the original ones.
But if the attacker uses the social engineering attack mentioned at the beginning he could succeed by simply modifying the IBAN details (instead of the Amount and the Name of the Recipient):
Can you spot the difference? Maybe yes (the IBAN visibly changed), but many details are unchanged from the original transaction. This fact will probably fool many users.
The main reason is that additional details, such as the Recipient are considered trusted by the user and can have influence upon his choices. The details provided to the user should be the lowest as possible; any further detail which is not completely trusted by the bank itself may lead to confusion and leading to considerably increase the attack surface.
For banking network security reasons, be sure to threat correctly banking transfers with incongruent details, on both online banking and phone banking operators' side.
Are you sure you are doing it correctly? Please check it, for the health of next generation security solutions.
The bad news is that one misbehaving entity is enough for lowering the security of the network. Attacker could choose the only bank in the country that has very weak controls, since the goal is to receive banking transfers from other people.
Let's assume that the bank where Mallory has his account will accept bank transfers if the the recipient is wrong and the amount transferred is lower than 5k. We could have a situation like the following one:
What If your bank will receive the correct account number with a wrong name on it? Well, the correct Beneficiary Name is not mandatory for issuing a bank transfer, but your bank (the receiving party) could accept it or not.Usually the attacker has still 3 additional days to phone the receiving bank and try to persuade one employee to finalize the transaction before the transfer gets blocked.
We did some tests about sending money in our country to correct IBAN account numbers, but to wrong recipients.
Some results:
- For amounts lower to 100 euros: 2 out of 7 banks confirmed and accepted the transfer.
- For and amount of 3000 euros: 1 out of 3 banks confirmed and accepted the transfer after a phone call.
Attackers may take advantage of these issues to perform social-engineering attacks directly on antimalware devices.
Effective attack strategy could be once again luring the user into confirming the wrong transaction, by preserving those fields that are actually remembered by the user. So which fields can be easily remembered?
- Amount? easily
- Recipient? easily
- Country? easily
- IBAN? Not easily. Personally I would just check for the name in the recipient field if it is available on the screen.
The main challenge in designing Antimalware solutions is to “Authenticate the Transactions to the user”. The most common way to meet this requirement is to provide an out of band channel that displays the transaction details in a secure manner. In this way the user can spot if “something” between him and the bank has interfered within the transmission.
Typical attacks against banking security solutions are impersonation attacks that need a malware already installed on the user system. The following is an example of a very common MITM (Man in the Middle Attack) performed on the local user machine:
Amount of Transaction: 300
Recipient: Alice
Country: Wonderland
IBAN: WL04292039280100000000918292
If an attacker using a malware capable of “Local Man in the Middle Attack” changes some of the details, the external devices will prompt for confirmation. At this point the transaction will look very different from the original one:
Amount of Transaction: 10000
Recipient: Mallory
Country: Wonderland
The IBAN: WL053510393501200000003523491
This fraud attempt is easy to spot, even if the attacker is using a mule in the same country as the victim: Transaction Amount and Recipient Details are very different from the original ones.
But if the attacker uses the social engineering attack mentioned at the beginning he could succeed by simply modifying the IBAN details (instead of the Amount and the Name of the Recipient):
The main reason is that additional details, such as the Recipient are considered trusted by the user and can have influence upon his choices. The details provided to the user should be the lowest as possible; any further detail which is not completely trusted by the bank itself may lead to confusion and leading to considerably increase the attack surface.
For banking network security reasons, be sure to threat correctly banking transfers with incongruent details, on both online banking and phone banking operators' side.
Are you sure you are doing it correctly? Please check it, for the health of next generation security solutions.
Client side Http Parameter Pollution - Yahoo! Classic Mail Video Poc
As a follow up of HTTP Parameter Pollution presentation,
I think it's time to give some details of the Yahoo! Classic Mail exploitation.
That's the long version of the video we showed @ OWASP Appsec Poland 2009:
Youtube LD Video or Wisec HD Video
Moreover, in order to better clarify the details of client side HPP explitation, here's an excerpt of my mail to Yahoo! security team:
"...
How client side HPP works?
It's pretty easy, find a name value pair of HTTP parameters and append %26aaaa=aaaaa to it. Example:
Have a look at Html source looking for translation of %26 in & or & in anchors or other attributes using the url, such as:
The semantic of such link changes from the function described to something else.
In fact, if instead of %26aaaa=aaa the injected parameter is:
Obviously it strongly depends on the functionalities and the structure of the Web app...
Yahoo! Classic Mail Issue
I found that client side HPP is possible on some parameter in the first page of Inbox.
For instance:
has "startMid" which could be used as entry point for client-side HPP.
In fact trying to add %26aaaa=aaa to startMid:
Every link to listed emails, within inbox, expands %26 into &.
Specifically:
(notice the &aaaa=aaa)
As a result, when the user will click on any email subject he will trigger the execution of a different action, as it usually happens for CSRF.
The proof of concept
I just analyzed the application and found that 'cmd' parameter is used in order to execute a specific action.
Later on, I found that:
cmd=fmgt.emptytrash
is the action for emptying the trashcan
and that:
DEL=1&DelFID=Inbox&cmd=fmgt.delete
forces the application to move every msg from a folder to the trashcan and then (if possible) deletes the folder.
Please note that every action has anti CSRF measures so it's not possible to perform those ones from an external evil page.
Then, by combining these two commands into a link using urlencoding for the first action (delete all messages) and double urlencoding for the second action (empty the trashcan) like this:
when the user clicks on any message in order to read it and then click to "Back to messages", he will have every messages deleted forever..
Countermeasures to Client Side HPP
When creating URLs the parameters taken from the HTTP request itself
should be url encoded and not translated to Html Entities.
Example (php):
and not:
The Attack flow
Let's review, once again, the attack flow:
Flow #1:
Flow #2:
Cheers,
Stefano
..."
Just to be clear, this vulnerability is currently patched and it affected the Yahoo! Mail classic version only.
However, it is likely to force a user to change the GUI from the brand-new mail interface to the old one.
I think it's time to give some details of the Yahoo! Classic Mail exploitation.
That's the long version of the video we showed @ OWASP Appsec Poland 2009:
Youtube LD Video or Wisec HD Video
Moreover, in order to better clarify the details of client side HPP explitation, here's an excerpt of my mail to Yahoo! security team:
"...
How client side HPP works?
It's pretty easy, find a name value pair of HTTP parameters and append %26aaaa=aaaaa to it. Example:
http://yahoo.com?par=val%26aaaa=aaa
Have a look at Html source looking for translation of %26 in & or & in anchors or other attributes using the url, such as:
<a href="http://yahoo.com?par=val&aaaa=aaa"> View </a>
The semantic of such link changes from the function described to something else.
In fact, if instead of %26aaaa=aaa the injected parameter is:
%26action=deleteIt becomes:
<a href="http://yahoo.com?par=val&action=delete"> View </a>so even if the user sees View, the action will be delete.
Obviously it strongly depends on the functionalities and the structure of the Web app...
Yahoo! Classic Mail Issue
I found that client side HPP is possible on some parameter in the first page of Inbox.
For instance:
http://it.mc257.mail.yahoo.com/mc/showFolder?fid=Inbox&order=down&tt=245&pSize=25&startMid=0
has "startMid" which could be used as entry point for client-side HPP.
In fact trying to add %26aaaa=aaa to startMid:
http://it.mc257.mail.yahoo.com/mc/showFolder?fid=Inbox&order=down&tt=245&pSize=25&startMid=0%26aaaa=aaaa
Every link to listed emails, within inbox, expands %26 into &.
Specifically:
<a href="http://it.mc257.mail.yahoo.com/mc/showMessage?pSize=25&sMid=0&fid=Inbox&sort=date&order=down&startMid=0&aaaaa=aaa&filterBy=&.rand=1076957714&midIndex=0&mid=1_62389_ALIKDNkAAJELSeg6IAXQeCc3b%2Fk&f=1">An email subject </a>
(notice the &aaaa=aaa)
As a result, when the user will click on any email subject he will trigger the execution of a different action, as it usually happens for CSRF.
The proof of concept
I just analyzed the application and found that 'cmd' parameter is used in order to execute a specific action.
Later on, I found that:
cmd=fmgt.emptytrash
is the action for emptying the trashcan
and that:
DEL=1&DelFID=Inbox&cmd=fmgt.delete
forces the application to move every msg from a folder to the trashcan and then (if possible) deletes the folder.
Please note that every action has anti CSRF measures so it's not possible to perform those ones from an external evil page.
Then, by combining these two commands into a link using urlencoding for the first action (delete all messages) and double urlencoding for the second action (empty the trashcan) like this:
http://it.mc257.mail.yahoo.com/mc/showFolder?fid=Inbox&order=down&tt=245&pSize=25&startMid=0%2526cmd=fmgt.emptytrash%26DEL=1%26DelFID=Inbox%26cmd=fmgt.delete
when the user clicks on any message in order to read it and then click to "Back to messages", he will have every messages deleted forever..
Countermeasures to Client Side HPP
When creating URLs the parameters taken from the HTTP request itself
should be url encoded and not translated to Html Entities.
Example (php):
<a href="/?startmid="<?=urlencode($_GET['startMid'])?>&id=4">View</a>
and not:
<a href="/?startmid="<?=htmlspecialchars($_GET['startMid'])?>&id=4">View</a>
The Attack flow
Let's review, once again, the attack flow:
Flow #1:
- Attacker sends an email to the victim with the above link.
- User/victim clicks on the link and gets the inbox page again.
- User/victim clicks in order to see the other messages and gets every message deleted.
Flow #2:
- User/victim visits a malicious page
- Attacker, after checking if the user is logged in on Yahoo!, redirects the victim on the malicious url.
- User/victim clicks in order to see the other messages and gets every message deleted.
Cheers,
Stefano
..."
Just to be clear, this vulnerability is currently patched and it affected the Yahoo! Mail classic version only.
However, it is likely to force a user to change the GUI from the brand-new mail interface to the old one.
Tuesday, May 19, 2009
Http Parameter Pollution a new web attack category (not just a new buzzword :p)
On May 14th @ OWASP Appsec Poland 2009, me & Luca Carettoni presented a new attack category called Http Parameter Pollution (HPP).HPP attacks can be defined as the feasibility to override or add HTTP GET/POST parameters by injecting query string delimiters.
It affects a building block of all web technologies thus server-side and client-side attacks exist.
Exploiting HPP vulnerabilities, it may be possible to:
- Override existing hardcoded HTTP parameters.
- Modify the application behaviors.
- Access and, potentially exploit, uncontrollable variables.
- Bypass input validation checkpoints and WAFs rules.
You can download the slides of the talk here (pdf) or browse it on Slideshare.
Also, we'll soon release a whitepaper in order to clarify all details about HPP.
As last news, in a few days the video of "Yahoo! Classic Mail" exploitation of Client Side HPP will be available on this blog.
So...stay tuned!
Friday, February 13, 2009
FOSDEM 09
Matteo Meucci was invited to talk about the new OWASP Testing Guide and Secure Software Development at FOSDEM 09.
FOSDEM
Presentation
Here you can download the video of the presentation:
Testing Guide video
The following is the interview that Christophe Vandeplas gives to Matteo and Paulo Coimbra (OWASP Project Manager):
Hi, thank you for the interview. I have been working in Information Security for some years, starting with a thesis in PKI and Attribute Certificates. I worked for many consultancy firms, then in 2007 with Stefano Di Paola and Giorgio Fedon we decided to create Minded Security, a company totally focused on Application Security Consultancy. I have been contributing to OWASP for many years and in 2005 I founded the Italian Chapter and from 2006 I lead the OWASP Testing Guide Project.
What will your talk be about, exactly?
The goal is to show the OWASP testing methodology and how you can implement a software development lifecycle that permits to develop more secure applications.
What do you hope to accomplish by giving this talk? What do you expect?
I’d like to promote the OWASP guidelines and find more people interested in OWASP and contributing to improve our projects.
What's the target audience for the OWASP Testing Guide?
We make this guide available in a completely free and open way because we believe sharing knowledge could contribute to develop more secure applications. The target audience here is not only the Application Tester, but everyone involved in the Software Development Life Cycle. So the Security Managers, the Internal Audit, the Developer Team, the Testers, are all interested to adopt a common and open source methodology to test the security of the application.
How would you describe the OWASP Testing Guide in a few sentences?
An open and standard methodology to perform Web Application Penetration Testing.
What are the biggest differences between v2 and v3 of the OWASP Testing Guide?
That's a good point. OWASP started in 2005 with the first testing guide version. We collected the set of test to perform and a short methodology. In 2006 we did a great job creating version 2 that collects 8 categories of tests for a total amount of 48 controls. The guide describes each single control to test.
Now v3 collects 10 categories of tests for a total amount of 66 controls and we have created a shared methodology in a 347 pages book.
How successful was the OWASP Summer of Code 2008? How many participants were there? What were the most important accomplishments during this period? What are the differences with the OWASP Spring of Code 2007 and OWASP Autumn of Code 2006?
Paulo Coimbra (OWASP Project Manager): OWASP Foundation is a voluntary, not-for-profit entity and open community. By responding so significantly to the Summer of Code’s challenge, this community has showed its vitality and true passion in improving application security.
We have invested roundly 275,000 dollars to fund the entire Summer of Code initiative. We have used slightly less than half of this amount to symbolically reward the work of one hundred project leaders, contributors and reviewers.
The remaining budget has been used to support the inter-linked OWASP Summit, a thrilling event set up to identify, coordinate, and prioritize OWASP efforts to create a more secure Internet in which the Summer of Code deliveries were publicly presented.
As it was said by OWASP Chair Jeff Williams, "Our community is growing and organizing into a powerful movement that will affect software development worldwide" and so the Summit, being the Summer of Code 2008 its central piece, has marked a major milestone in our efforts to improve application security.
Apart from launching more than two dozen of new or updated documents and tools, as for the most important accomplishments during this period, we would like to point out the reinforcement of an amazing knowledge sharing culture plenty of comradeship, curiosity and freedom.
Given OWASP´s worldwide scope characteristic, several of its contributors from all earth corners had been collaborating to develop application security for several years often without personally meeting each other. By gathering the majority of the most active of them in a friendly and productive environment, both events the OWASP Summer of Code 2008 and the OWASP Summit have created the conditions for enhanced future achievements. This circumstance and an improved organizational support should have been the major differences relatively to the past seasons of code.
What can we expect from the OWASP Winter of Code 2009?
Paulo Coimbra (OWASP Project Manager): Although the OWASP Winter of Code 2009 design is not finished yet and so its final frame can yet be modified by the expected OWASP community inputs, I believe the new season of code to be very similar to the previous one.
Likely by the next month the call for applications will be sent and we will be accepting proposals in three distinct spheres, namely, Innovation/Start-ups, Integration/Development and Quality Improvement.
The entire cycle from launching to completion should last nearly six months and we will be expecting all the approved proposals to be executed in time to be presented in our next Summit which will be probably held next November.
Even if we are expecting applications from the majority of the former season of code participants, we certainly welcome new ones. In addition, to review the approved projects, several positions will also be open.
We are counting on involving no less than hundred people in the OWASP Winter of Code 2009 and we hope you can be one of them. Please check our main page for updates.
You have more than 8 years of experience in information security. What have you seen changing in this period with respect to web application security? Are most types of vulnerabilities still the same or are there any genuinely new developments?
The research on Application Security is a very active field. We are finding new vulnerabilities and new types of attack every week. That's why we have to verify continuously the security of a web application also if the application is not changed during that time.
What do you consider the most underestimated risk for web applications in the near future?
Every application is completely different from the others. Web Application Security is dynamic, it changes every day. The risk for the Companies is to think statically: If you think statically to your application probably you will expose that to some security trouble in the future. That’s why keeping up-to-date is a key factor for the Companies: the OWASP Community could contribute giving state of the art open guidelines and tools.
FOSDEM
Presentation
Here you can download the video of the presentation:
Testing Guide video
The following is the interview that Christophe Vandeplas gives to Matteo and Paulo Coimbra (OWASP Project Manager):
Hi, thank you for the interview. I have been working in Information Security for some years, starting with a thesis in PKI and Attribute Certificates. I worked for many consultancy firms, then in 2007 with Stefano Di Paola and Giorgio Fedon we decided to create Minded Security, a company totally focused on Application Security Consultancy. I have been contributing to OWASP for many years and in 2005 I founded the Italian Chapter and from 2006 I lead the OWASP Testing Guide Project.
What will your talk be about, exactly?
The goal is to show the OWASP testing methodology and how you can implement a software development lifecycle that permits to develop more secure applications.
What do you hope to accomplish by giving this talk? What do you expect?
I’d like to promote the OWASP guidelines and find more people interested in OWASP and contributing to improve our projects.
What's the target audience for the OWASP Testing Guide?
We make this guide available in a completely free and open way because we believe sharing knowledge could contribute to develop more secure applications. The target audience here is not only the Application Tester, but everyone involved in the Software Development Life Cycle. So the Security Managers, the Internal Audit, the Developer Team, the Testers, are all interested to adopt a common and open source methodology to test the security of the application.
How would you describe the OWASP Testing Guide in a few sentences?
An open and standard methodology to perform Web Application Penetration Testing.
What are the biggest differences between v2 and v3 of the OWASP Testing Guide?
That's a good point. OWASP started in 2005 with the first testing guide version. We collected the set of test to perform and a short methodology. In 2006 we did a great job creating version 2 that collects 8 categories of tests for a total amount of 48 controls. The guide describes each single control to test.
Now v3 collects 10 categories of tests for a total amount of 66 controls and we have created a shared methodology in a 347 pages book.
How successful was the OWASP Summer of Code 2008? How many participants were there? What were the most important accomplishments during this period? What are the differences with the OWASP Spring of Code 2007 and OWASP Autumn of Code 2006?
Paulo Coimbra (OWASP Project Manager): OWASP Foundation is a voluntary, not-for-profit entity and open community. By responding so significantly to the Summer of Code’s challenge, this community has showed its vitality and true passion in improving application security.
We have invested roundly 275,000 dollars to fund the entire Summer of Code initiative. We have used slightly less than half of this amount to symbolically reward the work of one hundred project leaders, contributors and reviewers.
The remaining budget has been used to support the inter-linked OWASP Summit, a thrilling event set up to identify, coordinate, and prioritize OWASP efforts to create a more secure Internet in which the Summer of Code deliveries were publicly presented.
As it was said by OWASP Chair Jeff Williams, "Our community is growing and organizing into a powerful movement that will affect software development worldwide" and so the Summit, being the Summer of Code 2008 its central piece, has marked a major milestone in our efforts to improve application security.
Apart from launching more than two dozen of new or updated documents and tools, as for the most important accomplishments during this period, we would like to point out the reinforcement of an amazing knowledge sharing culture plenty of comradeship, curiosity and freedom.
Given OWASP´s worldwide scope characteristic, several of its contributors from all earth corners had been collaborating to develop application security for several years often without personally meeting each other. By gathering the majority of the most active of them in a friendly and productive environment, both events the OWASP Summer of Code 2008 and the OWASP Summit have created the conditions for enhanced future achievements. This circumstance and an improved organizational support should have been the major differences relatively to the past seasons of code.
What can we expect from the OWASP Winter of Code 2009?
Paulo Coimbra (OWASP Project Manager): Although the OWASP Winter of Code 2009 design is not finished yet and so its final frame can yet be modified by the expected OWASP community inputs, I believe the new season of code to be very similar to the previous one.
Likely by the next month the call for applications will be sent and we will be accepting proposals in three distinct spheres, namely, Innovation/Start-ups, Integration/Development and Quality Improvement.
The entire cycle from launching to completion should last nearly six months and we will be expecting all the approved proposals to be executed in time to be presented in our next Summit which will be probably held next November.
Even if we are expecting applications from the majority of the former season of code participants, we certainly welcome new ones. In addition, to review the approved projects, several positions will also be open.
We are counting on involving no less than hundred people in the OWASP Winter of Code 2009 and we hope you can be one of them. Please check our main page for updates.
You have more than 8 years of experience in information security. What have you seen changing in this period with respect to web application security? Are most types of vulnerabilities still the same or are there any genuinely new developments?
The research on Application Security is a very active field. We are finding new vulnerabilities and new types of attack every week. That's why we have to verify continuously the security of a web application also if the application is not changed during that time.
What do you consider the most underestimated risk for web applications in the near future?
Every application is completely different from the others. Web Application Security is dynamic, it changes every day. The risk for the Companies is to think statically: If you think statically to your application probably you will expose that to some security trouble in the future. That’s why keeping up-to-date is a key factor for the Companies: the OWASP Community could contribute giving state of the art open guidelines and tools.
Wednesday, February 11, 2009
OWASP-Italy Day III - Next 23rd February
OWASP Day III - "Web Application Security: research meets industry"
Background:
Open Web Application Security Project (OWASP) is a worldwide free and open community focused on improving the security of application software. OWASP mission is to make application security "visible," so that people and organizations can make informed decisions about application security risks.
Everyone is free to participate to the OWASP community and all the produced materials are available under a free and open software license.
The OWASP Day 3 follows the success of the past OWASP Italy Day and, in particular, the OWASP-Day II that received 250 subscriptions of attendees come from widespread business area: Telecommunication, Finance, Banking, Assurance, Government Companies.
Goals and Topics:
The OWASP Days have always offered a forum for discussion and exchange of ideas among researchers and practitioners who present their experiences and discuss issues related to Web Application Security from a higher level to a technical point of view.
Conference topics include, but are not limited to:
* The evolution of attacks and countermeasures for the security in the Web Application
* Case studies of how the Companies have adopted the OWASP Guidelines in their SDLC.
* Application Security Assessment Model
* Data Privacy Enabling Technology
* Experience report in applying OWASP guidelines to industries
Agenda
The detailed agenda of the conference is available here:
OWASP-Italy Day III
Registration and fee:
The conference is open to all attendees for free (coffee break and business lunch are included) but it requires (mandatory) registration at the following URL:
http://www.daisy-net.com/owasp
In order to guaranty a well organized event, the unregistered attendees will not be allowed to access the conference.
Location:
The OWASP-Italy Day III will be hosted by:
Centro di Competenza ICT SUD - Puglia
Department of Informatics
University of Bari
Via E. Orabona n.4.
70125 - Bari
Italy
Details and Location
Official site
Location
Background:
Open Web Application Security Project (OWASP) is a worldwide free and open community focused on improving the security of application software. OWASP mission is to make application security "visible," so that people and organizations can make informed decisions about application security risks.
Everyone is free to participate to the OWASP community and all the produced materials are available under a free and open software license.
The OWASP Day 3 follows the success of the past OWASP Italy Day and, in particular, the OWASP-Day II that received 250 subscriptions of attendees come from widespread business area: Telecommunication, Finance, Banking, Assurance, Government Companies.
Goals and Topics:
The OWASP Days have always offered a forum for discussion and exchange of ideas among researchers and practitioners who present their experiences and discuss issues related to Web Application Security from a higher level to a technical point of view.
Conference topics include, but are not limited to:
* The evolution of attacks and countermeasures for the security in the Web Application
* Case studies of how the Companies have adopted the OWASP Guidelines in their SDLC.
* Application Security Assessment Model
* Data Privacy Enabling Technology
* Experience report in applying OWASP guidelines to industries
Agenda
The detailed agenda of the conference is available here:
OWASP-Italy Day III
Registration and fee:
The conference is open to all attendees for free (coffee break and business lunch are included) but it requires (mandatory) registration at the following URL:
http://www.daisy-net.com/owasp
In order to guaranty a well organized event, the unregistered attendees will not be allowed to access the conference.
Location:
The OWASP-Italy Day III will be hosted by:
Centro di Competenza ICT SUD - Puglia
Department of Informatics
University of Bari
Via E. Orabona n.4.
70125 - Bari
Italy
Details and Location
Official site
Location
Subscribe to:
Posts
(
Atom
)