[WEB SECURITY] Experience with using HTTP proxy tools for QA testers
andreg at gmail.com
Mon Feb 28 19:28:37 EST 2011
On Mon, Feb 28, 2011 at 4:38 PM, Rohit Sethi <rklists at gmail.com> wrote:
> Thanks Andre - interesting perspective. With respect to QA automation, you
> might be right about the correlation between security and QA hygiene. Some
How do you propose that we get more information about the differences?
This is an interesting area of study for us.
> of the clients are actually quite mature with respect to application
> security process (when compared to others in their respective industries);
> generally their QA processes are less consistent between groups.
Repeat clients or new clients? :> How long on average do they take to
go from immature to mature? How many never go from immature to mature?
> Regarding pen testing in early iterations, this would work well but the
> problem is often scalability. One reason dynamic testing tools are so
> popular is because many organizations are unable/unwilling to have enough
> penetration testers to get involved with every application at every
> iteration (or early on in testing in waterfall shops).
I believe that runtime appsec testing is best when combined with
someone immediately empowered to rewrite source code. Certainly this
cannot be done on every project.
For the projects that haven't yet seen this collaboration, it would
make most sense to derive a positive model for appsec controls based
on a risk management gap analysis, where existing controls are
documented (and risks merely accepted) and planned controls are sent
to project management (such as a PMO), where risks can be fully
Again, I believe that risks can be best mitigated by planting two warm
bodies together -- one that has the expertise to find security-related
bugs (a very specialized skill), and one who has the experience to fix
their root cause (without interfering too much with other project
requirements -- usually a balancing act). Many years ago I figured
this could be one role: the security bugfixer, but with more
experience and exposure to these issues I am begging to see that the
roles must remain separate, but work more and more co-operatively
using formalized collaboration techniques.
> I think there are some cases of low hanging fruit. For example session
> fixation, authentication throttling / lockout, forcible browsing, limited
> CSRF testing (assuming they can leverage domain knowledge), picking up on
> verbose error messages, etc. Even some basic parameter manipulation &
> horizontal privilege escalation may be possible with clear guidance on an
> HTTP proxy tool. I agree that most of these could be picked-up by
> penetration testers more efficiently and accurately. I'm currently working
> with some QA shops now, so I'll let you know effective it ends up being.
In some of these suggested cases, system administrators (or devops)
are seemingly just as capable. However, now it becomes a matter of who
is responsible/accountable. I believe that QA and sysadmin people are
not equipped with the risk assessment background necessary to fulfill
these roles appropriately, and that information security professionals
are (or should be, because it's on their professional roadmap at the
However, in rare cases with some verticals (e.g. ones dealing with
financial information exchange such as stock exchanges) the quality
testing and system administration personnel are certainly capable of
dealing with risk assessment because it is part of their job. I'm not
going to rule it out, but this is very situational and one-off.
OTOH, we as application security professionals could certainly use all
of the help we can get. This is why ad-hoc leadership in the QA and
IT/Ops teams is necessary during crisis management, or during
quarterly/yearly reviews. It's more of an outreach program,
spear-headed by an information security management team or risk
management team. There will always be key stakeholders, but they
shouldn't be relied upon during day-to-day or week-to-week
results-oriented project reporting.
> Seasoned testers can certainly teach us a lot. I'm learning a lot from them
> right now and I suspect many other security people could as well. Any ideas
> on ways to improve the knowledge sharing from QA to security more generally?
I think we should leverage their tools. That's a great start, right?
For example, take a dev-tester's pimped-out Eclipse test automation
suite that they developed using JUnit and HtmlUnit and then proxy it
(no intercept) with Burp Pro or Fiddler, saving a Burp session file or
Fiddler SAZ file.
We should also share documentation. I develop domain models and
data/execution flow models in my head or sometimes model them in
Visio, software architect, or mindmapping apps. Quality testers would
probably like to see this stuff, and we would probably like to see
theirs. Looking at the whole of developers, testers, and app
pen-testers -- developers tend to do the least amount of work on
documentation and reporting -- but this may vary depending on a lot of
factors. We need to learn how to best leverage our existing
intellectual leadership in the software quality/security space.
I've seen HP QC and IBM QM based ALM implementations, but perhaps not
as often as Atlassian ALM. Most dev shops, quality testers, and IT/Ops
staff tend to document their ALM using Confluence. Sometimes, less
often seen, is Sharepoint or MediaWiki (or another similar
collaborative tool). I just had a great idea -- I'd like to see more
information security management and risk management practices put
their information in Confluence (if that's what the appdevs, QA, or
IT/Ops staff use) so it's all in one place. A lot of information
security management teams are too entrenched in the business-oriented
backoffice infrastructure (e.g. the company-approved Sharepoint
instance instead of the company-approved Confluence instance) and lack
having any presence in the technology / application development
infrastructure. You'll see an appsec portal that is totally
disconnected and largely ignored by app development teams, even if the
CxO(s) or auditors know about it.
More information about the websecurity