Week 2 Assignment

Due Sunday, September 17, 2006

  1. User Form Requesting Username & Password

    Assignment 1 - Part A

    Here is my example of a weak/insecure authentication application.

    This is a basic insecure login that connects to a database and compares the sesson $Request variables to userid and password entries in a database. If there is a match it sends the user to a Logged In page.

    The reason it is insecure is because there are no checks on input data length nor is there any kind of data "sanitization" of the user input making the app susceptible to buffer overflows, SQL injections and cross-scripting. There are other things that make this code insecure but the secure authentication example below explains more about checks and balances that can be applied to make the app more secure.

    Assignment 1 - Part B

    Here is an example of a more secure authentication application. The following checks have been applied to help prevent buffer overflows:

    • The form fields are limited to a certain number of characters using the maxlength input attribute
    • PHP's strlen() function is used to compare the field limit with the input. If the form max limit on the input field doesn't work this should
    • Both userid and password are run thru the PHP functions strip_tags(), htmlspecialchars() and trim()

    Here is the Safer Authentication Code -

    More Details:

    • The database lives outside the webserver and has limited privilege for app users
    • Database connection info and safe query functions are kept in a php file include in a password protected directory (versus a text file include)
    • Content-Type Header declares UTF-8 as well as in the meta-tag charset
    • All error messages are generic
    • sha1() encryption is used on the password input
    • $_POST session variables are used instead of $_REQUEST
    • The form method uses POST not GET
    • SQL statement is limited to returning 1 row of info
    • A Session variable is set when there is a match in the database
    • After 3 failures to login, the login form is removed and a message displayed to contact the sys admin. An email alert is sent to me telling me the userid that is "locked out" (in this program a user is not really locked out because all they have to do is clear their session)
    • The logout page destroys the session

  2. Buffer Overflow Attack - Simple Description

    Code Red is a worm that's (from what I have read) now in its 3rd revision and has been infecting Windows Web Servers due to a known Buffer Overflow in them. There is a patch but some server admins don't use it or don't patch in a timely manner allowing individuals to write code that exploits the security hole.

    How a Buffer Overflow Happens - UNCHECKED BUFFERS - computer programs are made up of subroutines called by the programs main routine. The subroutine does its thing then returns control back to the main routine. Each subroutine saves information that they need into a memory area called the stack. One thing that is stored is the memory address of where the subroutine should return control when it's finished. If a stack buffer is overflowed other buffers and the stack frame's return address are overwritten. Example: A program might have a text entry box for users to type text. If the user types more text then allowed a buffer overflow can occur.

    How this Buffer Overflow can be Used - MALICIOUS CODE can be executed at the overflow point by redirecting to another point that immediately follows the overflow, and injecting malicious code. Thus, instead of processing the plain text expected from our text entry box, there could now be compiled source code designed to run another program. The injected code could be as simple as popping up a message or it could be something more complex, powerful and dangerous.

    From my research, it appears that reading or writing past the end of a buffer can cause lots of different problems:

    • Programs can act strangely
    • Programs can fail completely
    • Programs can proceed without noticeable differences (but that doesn't necessarily mean nothing is happening)

    The side effects of a buffer overrun depend on:

    • how much data is written past the buffer bounds
    • what data (if any) is overwritten when the buffer gets full
    • whether the program tries to read the data that was overwritten

    The important thing to realize about buffer overflows is that any data allocated near the buffer can potentially be modified when the overflow occurs.

    It appears that sanitizing user input and output helps to prevent Buffer Overflows as well as the other 2 popular exploits of Cross-scripting and SQL Injection