i really don't see how this is at all an 'insider' attack; given that
it is the common attack vector for almost every single remote exploit
strategy; look into the inner protocol of the specific app and form
your own messages to exploit it.
On 8/15/07, Gary McGraw <[EMAIL PROTECTED]> wrote:
> Hi
r for CTO's to fob it off as too hard.
if you specifically define it it can be acted on and solved. expanding
the definition will only complicate matters, imho.
>
> gem
>
> p.s. I added a little bit of data on the justice league blog about this:
> http://www.cigital.com/justiceleag
your plan would simply result in vendors denying the existence of bugs.
i still think all these ideas are wrong and the model is simple: don't
employ people who write and generate insecure code. it's just part of
programming. you wouldn't hire a doctor to be a gardener. don't hire
an idiot to prog
On Dec 1, 2007 7:59 AM, Steven M. Christey <[EMAIL PROTECTED]> wrote:
>
> On Fri, 30 Nov 2007, silky wrote:
>
> > i still think all these ideas are wrong and the model is simple: don't
> > employ people who write and generate insecure code. it's just part of
y kept in mind.
Hold a lot more what? This doesn't make sense.
--
noon silky
http://lets.coozi.com.au/
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charte
