Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security SecProg
[Top] [All Lists]

RE: Microsoft Writing Secure Code

Subject: RE: Microsoft Writing Secure Code
Date: Fri, 7 Jan 2005 07:38:08 +0200

Hi Lawrence

Please explain what you mean with "...Given option 3 we know we can't trust the 
authentication routine.."

I am not understanding what you mean with this.

Regards
  Anton

-----Original Message-----
From: Lawrence Landauer (SECURITY)
[mailto:lawrenl@exchange.microsoft.com]
Sent: 06 January 2005 09:05
To: priestmaster; Damhuis Anton
Subject: RE: Microsoft Writing Secure Code


None of the three options is secure. Given option 3 we know we can't
trust the authentication routine.  Given that: Option 1 gives the admin
info to anonymous or invalid users, Options 2 and 3 both let an attacker
brute force valid usernames?

- L

-----Original Message-----
From: priestmaster [mailto:priest@priestmaster.org]
Sent: Thursday, January 06, 2005 8:16 AM
To: Damhuis Anton
Cc: secprog@securityfocus.com
Subject: Re: Microsoft Writing Secure Code

Hi,

The third is the most secure I think. If you know how exploitation of
vulnerabillites work, you can secure it easily. You need much security
knowledge to create complex and secure software. Security experts also
make mistakes and create security-releated bugs. No one is perfect.

greets,

priestmaster
----- Original Message -----
From: "Damhuis Anton" <DamhuisA@aforbes.co.za>
To: <secprog@securityfocus.com>
Cc: "Michael Howard" <mikehow@microsoft.com>
Sent: Tuesday, January 04, 2005 10:52 AM
Subject: RE: Microsoft Writing Secure Code



I have read the book "Designing Secure Web-based Applications", found it
quite informative but also somewhat disappointing.

I was (at the time) looking for a book that assists with "writing secure
code". Thus how code should be written, not the way code interfaces with
security components.

Example:
What is the best way to display User Details:

~~Suedo code Begin ~~
Option 1:
If var_userLevel = USER then
   ... display User info
else
  ... Display Admin Info
end if



Option 2:
If var_userLevel = ADMIN then
   ... display Admin info
else
  ... Display User Info Info
end if



Option 3:
If var_userLevel = ADMIN then
   ... display Admin info
elseif var_userLevel = USER
  ... Display User Info Info
else
  ... Capture Error
end if

~~Suedo code End~~


To me it is Option 3. Somewhat more work, but a lot more secure, then
Option 1. If for some reason someone else writes the code to get the
variable for var_userLevel , and that code is hackable, Option 3 will
withstand the attack a lot better then Option 1. Option 2 in this case
would also be better then Option 1, as Option 1 would display the Admin
info for anybody other then user. Option 2 in this case would revert
back to the lower level of access. Thus just structuring the If stament
differently in Option 1 and 2, already makes the code more secure.

Also by logging all the errors in option 3's last "Else" statement one
can look for any thing overlooked initially (and capture any unknown
hacker attacks -although this is reactively)

Regards
  Anton


Confidentiality Warning
=======================
The contents of this e-mail and any accompanying documentation are
confidential and any use thereof, in what ever form, by anyone other
than the addressee is strictly prohibited.



Confidentiality Warning
=======================

The contents of this e-mail and any accompanying documentation
are confidential and any use thereof, in what ever form, by anyone
other than the addressee is strictly prohibited.

<Prev in Thread] Current Thread [Next in Thread>