On Wed, Feb 23, 2005 at 10:19:11PM +0100, Uwe Hermann wrote:
> Hi everyone,
Hi!
> My question is whether anyone knows of an automated tool (similar to
> rats or flawfinder) which can check if a web application is vulnerable
> to (at least some specific forms of) XSS or not.
I don't know of any. When I do web application audits I either do it by
analysing the application logic (from the outside) or through a code review
(which is usually best)
> In my case, I would like to know if the patch I applied to info2www
> really fixed the XSS problems or not, and if it fixed _all_ problems.
You can ask here for other people to review your info2www release (with the
patch) and try to find XSS there.
> On a related note, I intend to do some auditing of packages (Debian, as
> well as non-Debian) myself in the nearer future. What is the usual
> procedure you use when finding security issues and what do you do first:
> Inform the Security Team? Report a bug? Try to find a patch? Publish
> the issue on Bugtraq etc?
I believe the procedure is documented in the website
(www.debian.org/security/audit) in any case. I (personally) take the
following steps (and in this order):
1- try to produce a patch (if the fix is simple)
2- report the issue to the security team (if the bug is present in a
released version of Debian), provide a detailed analysis and a patch
3- report the bug to the maintainer and to upstream (in all cases), provide
the analysis and the patch.
BTW, I usually don't provide attack samples (or POC) if the bug is
self-evident. I find that a waste of time. If there is a bug in the code
and is self-evident, there should be no need to justify a fix by producing
a POC. If the implications of the bug are not all to clear, and I have
sufficient time (which is not usually the case), I might try to produce a
sample exploit in points 2) and 3).
IF the Security Team says that the issue can go "public" or IF the bug only
affects an unreleased version of Debian file a bug in the BTS with the
proper priority so the package is not pushed to testing and, if it's in
testing, so its removed from there before release if a fix is not produced.
As for Bugtraq et al, I don't usually post there, I leave that to the DSAs
that the Security Team posts when a new package is published with a fix in
a released Debian version.
> Apropos Bugtraq: Which mailing lists or other forums, websites etc. do
> you use to publish security issues which also affect non-Debian systems?
The Security Team uses vendor-sec, which is a closed, invitation-only,
mailing list for Linux vendors (so it's not a public mailing list). If you
wish to publish security issues which affect non-Debian systems you can
either ask the Security Team to forward that to vendor-sec or publish to
Bugtraq or full disclosure. I actually favor the first.
I actually don't have time to track if all vendors are vulnerable when I
find something that is and don't contact the different distributions that
might repackage upstream's work. I leave that up to the upstream maintainer
and to the Debian Security Team. As for Bugtraq or full-disclosure, I don't
send anything there myself, as I've already said.
In any case, I do this because I'm looking for low-hanging fruit (stuff
that is easy to find and anyone can audit himself). If I were to find a
remote buffer overflow in, say, OpenSSH, I would probably do stuff
differently.
Regards
Javier
signature.asc
Description: Digital signature
|
