Sometimes organizations have to put their hand in the fire before they
understand what it feels like to get burned.
Unfortunately, if it's a banking site, it may not be only the organisation
that gets burned.
Matt Palmer
-----Original Message-----
From: Yvan G.J. Boily [mailto:yboily@seccuris.com]
Sent: 26 October 2004 16:27
To: 'Cory Foy'; secprog@securityfocus.com
Subject: RE: Web Site Vulnerabilities
Your course of action is dictated by the amount of liability and
confidentiality you have assumed.
If you have signed an NDA then there is little you can do after explaining
the issue. If there is no NDA and you feel confident
that you are correct you can inform them that you will go public with your
information in a reasonable period of time.
If you choose to go public, then allow them the opportunity to correct the
issue before going public, and make sure that there is
nothing (i.e. DMCA and such) which could be used to assign legal liability
to you.
Realistically speaking though, if they don't believe it is an issue, and you
have tried to educate them, then you have done the best
you can. Sometimes organizations have to put their hand in the fire before
they understand what it feels like to get burned.
Yvan
-----Original Message-----
From: Cory Foy [mailto:usergroup@cornetdesign.com]
Sent: Monday, October 25, 2004 6:43 PM
To: secprog@securityfocus.com
Subject: Web Site Vulnerabilities
Recently I came across two web sites that had various vulnerabilities.
One was subject to a basic SQL injection attack to log in to their customer
side, and the other was displaying ASP code in the page
that listed not only various function definitions, but login, URL and
passwords (including sa) for their database.
In both cases I have working relationships with the managers and sent an
email off to them. In both instances the managers replied
that they were aware of the issues and the SQL injection attacks, but didn't
feel it was a priority to fix.
On one of the sites I could understand. It is basically a portal to
publically available information, and no secure information is
stored in their system. The second was on a machine that passed
authentication information to a remote banking site and though I
don't know, would surmise that it might be possible to jump off of it if
compromised.
Have we really become so lax in our thinking that security issues such as
these can be shrugged off? Don't get me wrong, I'm not
suggesting that either of these cases should kill all development and
immediately fix it (though in the case of SQL injection
attacks it is so easy to fix...). But some response should at least be
justified (for example, with the banking site, whose vuln is
still present). Or is it fine to postpone worrying about problems such as
these if you don't think they will have an impact?
Cory
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
**********************************************************************
National Archives Disclaimer
This e-mail message (and attachments) may contain information that is
confidential to The National Archives. If you are not the intended recipient
you cannot use, distribute or copy the message or attachments. In such a case,
please notify the sender by return e-mail immediately and erase all copies of
the message and attachments. Opinions, conclusions and other information in
this message and attachments that do not relate to the official business of The
National Archives are neither given nor endorsed by it.
**********************************************************************
