Having failed dismally to keep this blog up to date .. I've started a new blog!
Its the official ZAP Blog and I intend to do a much better job of keeping it current.
The first post is a copy of a blog post I made on the Mozilla Security blog: OWASP ZAP: the Firefox of web security tools.
And its also open to anyone else who would like to post anything ZAP related, so if you'd like to do that then please get in touch.
And please note that making sure ZAP is the best web application security tool available for developers is a priority for me, so posts on the new blog should be of interest to anyone who has been following this one!
Simon
Penetration Testing For Developers
A blog about penetration testing aimed at web application developers and functional testers.
Friday 14 September 2012
Monday 4 July 2011
Developers Vs QA Vs Security testers
When developing software there are now 3 groups of teckies involved:
However when I was preparing for my OWASP talk for AppSec EU in Dublin, I started thinking about this a bit more.
And now I think that can be expanded:
Developers, QA and security testers all need to have a pretty good understanding of what the other 2 groups do.
So I'm saying you cant really be a good developer unless you know about QA (functional testing) AND about security testing.
You dont have to be an 'expert' in both areas, but you need to have a good grounding in each.
The former is actually quite common - most developers (at least in my experience) work pretty closely with QA and so should have picked up a fairly good idea of what they and how they do it. The latter, well, some do and some dont.
But the converse is also true - I dont think you can be a good security tester without knowing about both development and QA,
And you can be a good functional tester without knowing about both development and security testing.
Anyone feel like arguing against that? :)
Which group are you in, and how good is your understanding of the other 2 disciplines?
- Developers
- Functional testers (QA)
- Security testers
However when I was preparing for my OWASP talk for AppSec EU in Dublin, I started thinking about this a bit more.
And now I think that can be expanded:
Developers, QA and security testers all need to have a pretty good understanding of what the other 2 groups do.
So I'm saying you cant really be a good developer unless you know about QA (functional testing) AND about security testing.
You dont have to be an 'expert' in both areas, but you need to have a good grounding in each.
The former is actually quite common - most developers (at least in my experience) work pretty closely with QA and so should have picked up a fairly good idea of what they and how they do it. The latter, well, some do and some dont.
But the converse is also true - I dont think you can be a good security tester without knowing about both development and QA,
And you can be a good functional tester without knowing about both development and security testing.
Anyone feel like arguing against that? :)
Which group are you in, and how good is your understanding of the other 2 disciplines?
Saturday 11 June 2011
OWASP AppSec EU 2011 review
OK, OK, I've failed miserably to keep this blog even vaguely upto date.
But I've just got back from OWASP AppSec EU 2011, so a quick review is a good way to kick it off again.
I'm relatively new to the security 'scene' so it was the first major OWASP event I've been to, and I didnt really know what to expect.
What I found was a great bunch of people - friendly, helpful and supportive. I had a great time.
The location, venue and organization was excellent - obviously Dublin's a great city, and Trinity college was an ideal venue.
And congrats to the organizers - they did a really good job.
As there were 3 talks going on at any one time there were quite a few I wanted to go to but couldn't - I'll definitely watch them on video when they get posted.
Of the ones I did get to my favorites were:
How to become Twitter's admin: An introduction to Modern Web Service Attacks
That introduced me to a whole new range of web service specific attacks I didnt know about.
I think some people in the audience got a bit hung up on the fact that there were countermeasures to the examples given. But there are countermeasures to things like SQLi and XSS and they still happen all too frequently!
Integrating security testing into a SDLC
A very polished performance from the IBM speaker, but it was engaging and full of real world experience.
Python Basics for Web App Pentesters
I'm an old school perl hacker, and I've been meaning to delve into some of the newer scripting languages for ages.
And Justin's convinced me to go for Python first.
Putting the Smart into Smartphones
Packed room for this one, and for a very good reason.
Lots of really useful examples, advice and guidance.
And finally...
Obviously I cant really give an objective opinion about my own talk "An Introduction to the OWASP Zed Attack Proxy".
From my point of view there were things that could have gone better: my throat was killing me, and I had problems with the wireless mic (not used one before).
But the talk was well attended and seemed to go down well.
And it was a great place to showcase ZAP 1.3.0 (which I'll post about soon)!
Any feedback gratefully received (especially if its constructive;).
I'll post a link to the slides and video from here when they're uploaded.
Unless I really cant stand the video ;)
Psiinon
But I've just got back from OWASP AppSec EU 2011, so a quick review is a good way to kick it off again.
I'm relatively new to the security 'scene' so it was the first major OWASP event I've been to, and I didnt really know what to expect.
What I found was a great bunch of people - friendly, helpful and supportive. I had a great time.
The location, venue and organization was excellent - obviously Dublin's a great city, and Trinity college was an ideal venue.
And congrats to the organizers - they did a really good job.
As there were 3 talks going on at any one time there were quite a few I wanted to go to but couldn't - I'll definitely watch them on video when they get posted.
Of the ones I did get to my favorites were:
How to become Twitter's admin: An introduction to Modern Web Service Attacks
That introduced me to a whole new range of web service specific attacks I didnt know about.
I think some people in the audience got a bit hung up on the fact that there were countermeasures to the examples given. But there are countermeasures to things like SQLi and XSS and they still happen all too frequently!
Integrating security testing into a SDLC
A very polished performance from the IBM speaker, but it was engaging and full of real world experience.
Python Basics for Web App Pentesters
I'm an old school perl hacker, and I've been meaning to delve into some of the newer scripting languages for ages.
And Justin's convinced me to go for Python first.
Putting the Smart into Smartphones
Packed room for this one, and for a very good reason.
Lots of really useful examples, advice and guidance.
And finally...
Obviously I cant really give an objective opinion about my own talk "An Introduction to the OWASP Zed Attack Proxy".
From my point of view there were things that could have gone better: my throat was killing me, and I had problems with the wireless mic (not used one before).
But the talk was well attended and seemed to go down well.
And it was a great place to showcase ZAP 1.3.0 (which I'll post about soon)!
Any feedback gratefully received (especially if its constructive;).
I'll post a link to the slides and video from here when they're uploaded.
Unless I really cant stand the video ;)
Psiinon
Sunday 30 January 2011
OWASP Appsec Tutorial Series Episode 1
Jerry Hoff has just started a series of videos introducing people to OWASP and the world of application security.
Episode 1 is available here: http://www.youtube.com/watch?v=CDbWvEwBBxo
I think its a great start, and strongly recommend that everyone checks it out.
Psiinon
Episode 1 is available here: http://www.youtube.com/watch?v=CDbWvEwBBxo
I think its a great start, and strongly recommend that everyone checks it out.
Psiinon
Friday 31 December 2010
ZAP and Hoyt LLC Research
Just a quick post to let you all know that Hoyt LLC Research have offered to contribute to the development of ZAP, which is great news.
See http://www.cloudscan.me/2010/12/developer-java-zaproxy-open-source-low.html for more details.
See http://www.cloudscan.me/2010/12/developer-java-zaproxy-open-source-low.html for more details.
Tuesday 5 October 2010
OWASP Zed Attack Proxy
I'm pleased to announce that the Zed Attack Proxy has been accepted as an OWASP project.
Its new homepage is here: http://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
The next release of OWASP ZAP, planned for later this year, is expected to include:
Its new homepage is here: http://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
The next release of OWASP ZAP, planned for later this year, is expected to include:
- OWASP rebranding
- Improvements to the passive and active automated scanners
- Improvements the Spider
- The addition a basic port scanner
- The ability to brute force files and directories (using components from DirBuster)
- Further internationalization
Tuesday 28 September 2010
Exploring a web application with ZAP
This post explains how to explore the web application you are testing using the Zed Attack Proxy (ZAP).
There are downloads available for Windows, Mac OS and Unix / Linux like operating system.
You will need to have Java 1.6 or higher also installed.
Once you have downloaded and installed ZAP, start it up.
On Windows an icon will have been created on your desktop and an entry added to the start menu.
On other operating systems use the zap.sh command line script.
See Configuring Proxies help page or your browser's documentation if you are unsure of how to do this.
By default ZAP will listen on http://localhost:8080.
If necessary this can be changed via the Options connection screen.
Now try to connect to your application using your browser.
If you can not connect to it then check your proxy settings again. You will need to check your browser's proxy settings, and also ZAP's proxy settings. Its also worth checking that the application that you are trying to test is running!
When you have successfully connected to your application you will see one or more lines in ZAP's Sites and History tabs.
Note that most of ZAP's tabs provide additional functionality that can be accessed via 'right click' menus.
Follow all links, press all buttons and fill in and submit all forms.
Some automated security scanners just require you to login to your application and then explore it for you.
I do not recommend this approach.
It is much more effective to manually explore the application.
You are much more likely to submit valid data that will expose new functionality.
The automated scanner can supply the bad data in an attempt to compromise your application.
If your application has multiple roles then you should explore it with each role and save the sessions in separate files.
The Sites tab shows you a hierarchic representation of your requests, while the History tab shows them in the order you made them.
The History tab also shows you the HTTP response code, the time the request took and any Tags or Notes.
Tags are added automatically for pages that contain things like forms, hidden fields and scripts via the Passive Scanner.
These rules can be changed via the Options Passive Scan screen.
You can also tag requests manually.
Notes can contain much more information - they are for extra information that you want to record and are not generated automatically.
Clicking on an entry in either tab will show the details on the Request and Response tabs.
The History tab provides a filter dialog which allows you to restrict the requests listed to just the ones you are currently interested in.
The Search tab allows you to search for regular expressions in all of the URLs, requests and responses.
ZAP shows you all of the requests and responses that are going on 'under the covers' of your application.
This may be particularly revealing if the application uses AJAX requests to get information in the background.
Next we shall look at the automated tools the ZAP provides...
Download and install ZAP
You will need to download ZAP from http://code.google.com/p/zaproxy/downloads/list.There are downloads available for Windows, Mac OS and Unix / Linux like operating system.
You will need to have Java 1.6 or higher also installed.
Once you have downloaded and installed ZAP, start it up.
On Windows an icon will have been created on your desktop and an entry added to the start menu.
On other operating systems use the zap.sh command line script.
Change your browser to use ZAP as a proxy
Change your browser to use ZAP as a proxy, so that all of the requests and responses to and from your application go via ZAP.
See Configuring Proxies help page or your browser's documentation if you are unsure of how to do this.
By default ZAP will listen on http://localhost:8080.
If necessary this can be changed via the Options connection screen.
Now try to connect to your application using your browser.
If you can not connect to it then check your proxy settings again. You will need to check your browser's proxy settings, and also ZAP's proxy settings. Its also worth checking that the application that you are trying to test is running!
When you have successfully connected to your application you will see one or more lines in ZAP's Sites and History tabs.
Note that most of ZAP's tabs provide additional functionality that can be accessed via 'right click' menus.
Explore your application
Use your browser to explore all of the functionality provided by the application.Follow all links, press all buttons and fill in and submit all forms.
Some automated security scanners just require you to login to your application and then explore it for you.
I do not recommend this approach.
It is much more effective to manually explore the application.
You are much more likely to submit valid data that will expose new functionality.
The automated scanner can supply the bad data in an attempt to compromise your application.
Save the ZAP session
Once you have manually explored the application it would be a good time to save the ZAP session so that you can look at it again.If your application has multiple roles then you should explore it with each role and save the sessions in separate files.
What ZAP shows you
ZAP records all of the requests you make to the application and all of the responses you receive from it.The Sites tab shows you a hierarchic representation of your requests, while the History tab shows them in the order you made them.
The History tab also shows you the HTTP response code, the time the request took and any Tags or Notes.
Tags are added automatically for pages that contain things like forms, hidden fields and scripts via the Passive Scanner.
These rules can be changed via the Options Passive Scan screen.
You can also tag requests manually.
Notes can contain much more information - they are for extra information that you want to record and are not generated automatically.
Clicking on an entry in either tab will show the details on the Request and Response tabs.
The History tab provides a filter dialog which allows you to restrict the requests listed to just the ones you are currently interested in.
The Search tab allows you to search for regular expressions in all of the URLs, requests and responses.
ZAP shows you all of the requests and responses that are going on 'under the covers' of your application.
This may be particularly revealing if the application uses AJAX requests to get information in the background.
Next we shall look at the automated tools the ZAP provides...
Subscribe to:
Posts (Atom)