Projects

firefuzzer

Concept: In this age of the excessive INTERNET-dependency, the Web browser is the most basic common unit of the Internet experience for much of the global community. Also, it is the one which is the most attacked from external agencies. Thus, it is critical to test the Browser's ability to be ... [More] secure enough. Thus, to audit the security mechanisms in place within conventional Web Browsers, we plan to use a fuzzer codenamed 'FireFuzzer'. A fuzzer (also known as 'Fault Injectors') is a typically a tool that attempts to discover security vulnerabilities by injecting random input into the WEB application. If the program contains a vulnerability that can lead to an exception, crash or server error (in the case of web apps), it can be determined that a vulnerability has been discovered. Conventional Fuzzers are good at finding buffer overflow, DoS, SQL Injection, XSS, and Format String bugs. Firefuzzer is expected to perform black-box scans over the web pages. It will target the web page URL which is passed as an argument via command line and will mark the textboxes within the HTML forms to inject unacceptable data. Then, FireFuzzer will inject random textual data and submit the forms to see whether Exceptions are generated. Intended vulnerabilities expected to be targeted include: Buffer Overflow Database Injection (SQL Injections) File Handling Errors (fopen, readfile…) XSS (Cross Site Scripting) Injection Cross-site Scripting is commonly used to cause the execution of scripting code (controlled by the attacker) in order to steal information from the victim (e.g. current logged in session information) or cause the installation of Trojan horse software that can be later used to take full control of the victims host. SQL Injection is the process of injecting SQL language code within data requests that result in an application’s back-end database server either surrendering confidential data, or cause the execution of malicious scripting content on the database that results in a host compromise. Description: Firefuzzer is a penetration testing tool. The aim of the fuzzer is to discover unknown vulnerabilities in web applications. As per the requirement of the Project Proposal, the FireFuzzer application would be executed from the Command Prompt. It has two major modules: 1)Buffer Overflow 2)Cross Site Scripting (XSS) In the case of Buffer Overflow module, Firefuzzer creates random, possibly invalid text String and inserts into html input textboxes. All the Forms present on the given page are then submitted one after the other and appropriate look-up is performed for the status code response. Warnings are given for specific HTTP Codes. For a normal web page which loads properly without any error, HTTP Status Code 200 is sent as a response which means OK. HTTP Status Code 500 series of errors indicate exceptions caused at the Server End. In the case of Cross-Site Scripting module, Firefuzzer will also target SQL injections where SQL commands are injected into the Login form component. Attacker can also effectively insert code and modify SQL command. These commands are then passed to Server end. Again, Look-ups are performed for the status code response and appropriate warnings are issued. Execution Steps: Save the "inject.conf" file in the same folder as "Firefuzzer.jar" file. At command prompt, type "java -jar Firefuzzerr.jar {url} {buffer/sql} {detail(Optional)}" and the Program Execution will begin appropriately. Example: java -jar Firefuzzer.jar www.abcdefgh.com buffer => Buffer Overflow attack-summary java -jar Firefuzzer.jar www.abcdefgh.com buffer detail => Buffer Overflow attack-detailed java -jar Firefuzzer.jar www.abcdefgh.com sql => SQL Injection attack-summary java -jar Firefuzzer.jar www.abcdefgh.com sql detail => SQL Injection attack-detailed Team Members: 1)Gaurav Pandey (gip2103@columbia.edu) 2)Sumeet Jindal (sj2405@columbia.edu) Mentor: Prof. Herbert Thompson University: Columbia University (Software Security-Spring 2009) [Less]

gaurav-helping-hands

blah blah blah...

firewall-emulator

Firewall Emulator The assignment is to write a "stateless packet filter" and client/test case generator. Note carefully: both parts are necessary; a significant part of the grade on this assignment will depend on the client+test case generator. The firewall piece isn't a real ... [More] firewall, since we're not dedicating a machine to each student. Instead, it's a program that listens on a UDP port (note: not TCP) and reads packets addressed to that port that simulate actual packets. The first thing the firewall must do, though, is read a configuration file describing the policy to be enforced. Since this is not a compiler course, I will give a very simple input language. You must implement at least this language, The input is a series of lines of the following format: modifier where is either "block" or "allow" (without the quotes), is a dotted quad (e.g., 1.2.3.4) always followed by a length. Port is an integer. Either or may also be specified as "", which means "everything". modifier is an optional parameter; the only legal value is "established". The following are legal input lines: block 127.0.0.1/32 80 allow 192.168.2.0/24 allow 25 block 21 allow established The rules are an ordered list. Input records to the UDP port contain the fields necessary for filtering: sourceIP destIP sourcePort destPort Exactly five fields must be present on all records. SourceIP and destIP and dotted quads; sourcePort and destPort are integers. is either "start", "continue", or "end"; it says whether a packet is starting a connection, part of the middle of a connection, or ending one. A rule with "established" permits only packets with "continue" to match; rules without any modifier accept any packets. Note that this is a stateless packet filter; you do not need to track connection state. So -- the firewall reads the configuration file, then listens on a port for packets. A decision must be made, according to these rules, about accepting or dropping each packet. The output of the firewall is a list of packets received, their disposition, and the number of the rule that caused the action. The client program generates packets that are consumed by the firewall. If you wish, you may have multiple instances of the client running simultaneously, each generating different packets. Be aware that you are using UDP, which means it's easy to overflow the input queue for the firewall -- you'll have to rate-limit your senders. You want to make sure that all rules are tested. Of course, you also need to be sure that your rule set is complex enough give the clients a good workout -- you need overlapping rules, where the rule order is very important. [Less]

gaurav-java-workspace

This is my SVN Repository of Java Code.

tapestryx

My experiences dealing with the book 'Enjoying Web Development with Tapestry'

ghodnadikar

none

wikea

This is a project for a software engineering class at Columbia University.

idenman-apache-server

Developing Apache Web Server Module as well as Firefox Extension for Identity Management System