CSC 379:Research Assignment Sample: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
Line 78: Line 78:
* [http://www.cnn.com/TECH/computing/9910/11/id.theft.idg/ Fighting the Plague of Identity Theft] ''CNN''
* [http://www.cnn.com/TECH/computing/9910/11/id.theft.idg/ Fighting the Plague of Identity Theft] ''CNN''
* [http://www.theregister.co.uk/content/6/17358.html Stomp the identity thieves] Kevin Mitnick, ''TheRegister.co.uk''
* [http://www.theregister.co.uk/content/6/17358.html Stomp the identity thieves] Kevin Mitnick, ''TheRegister.co.uk''
== Source Files ==
* [http://ethics.csc.ncsu.edu/privacy/database/study.php '''Original Study Guide''']
* [http://ethics.csc.ncsu.edu/privacy/database/ '''Original Bibliography''']

Revision as of 12:52, 26 July 2008

Study Guide

The two main issues with database privacy are the actual security of the database itself and the legal and ethical implications of what can/should be stored on the databases in the first place. Also there should be a consideration of the intrinsic ethical duty placed on database security professionals to secure a database system.

How Database Information is Leaked

  • SQL Injection - One of the best known database exploits around, SQL injection involves sending unexpected data to a webserver which interacts with a database. The data may be sent through a few methods, but is always specially formed, containing SQL statements which can compromise any unprotected data source. Data is generally passed through either the address or through form variables.
    • Browser Method: When data is passed through the address to a page which interacts with a database, the data is passed in the form of variables appended to the end of the address. For example "www.cnn.com?id=1234" would pass 1234 as data to cnn.com If this data is directly used in a database command, one could alter 1234 in a specific way as to introduce a SQL command to be executed by the database. This ability could give the attacker a powerful tool to compromise data and accounts of an unprotected database. The users ability to change the address variables at will makes this an extremely easy database leak anyone can exploit
    • Form Method: Forms take data on one page and pass that data directly to another page for processing, usually with a backend database involved. The ease of the user’s ability to modify address variables is prevented since the form data, if passed properly, is hidden from the user. Since the transfer is hidden, sites will believe they have satisfactorily sanitized user input by enforcing rules (digits only for certain fields, length limits) with client side JavaScript. This is supposed to prevent users from entering SQL statements disguised as bad input, but a savvy user could download the source of the file and modify the data subverting any JavaScript. Entering erroneous SQL statements such as '; drop table users --could compromise an entire database and its users.
  • Preventing SQL Injection
    • Syntax Checking: The trick of any SQL injection attack is the user’s ability to insert malicious statements into invalidated user input. To protect against this problem users must sanitize input collected from the user on the server side. The types of sanitation that must be performed is the removal of any semicolons or back tick marks since these are the stronghold of the syntax required for a proper SQL injection.
    • While checking syntax is good, the best prevention of SQL injection is the use of something called a prepared statement. When using prepared statements, also known as stored procedures, every interaction with a database is prewritten allowing only enough rights as are required for any given command. Thus when an unexpected, powerful command is run there are not enough rights allocated for the malicious command under the ruse of a stored procedure to be properly executed even if it is properly inserted.

Database Security

When a carder by the handle "Maxus" broke into CD Universe's database records and gained access to over 250,000 credit card numbers from customers (link), the first thing everyone wanted to know was HOW. A single lapse in database security can doom an e-company to almost immediate failure and yet it seems we hear about events such as this happening all the time.

Database Security is integral in keeping our information private, regardless of who is maintaining the database itself. By far the most common break in security is the presence of plain-text log and/or data files on public web servers. The solution to this problem is relatively simple, either don't keep logs or use encryption. While encryption is beyond the scope of this topic, it can be used to effectively hinder the efforts of wouldbe cyber criminals. Another critical area that must be monitored are the administrators and users of the database. As in this case where a DEA Agent was found to have been selling information to various parties, all the encryption and frontend security means nothing if any user can have unchecked access to sensitive information. Keeping a checks and balances system on the users and administrators much the way a bank keeps tabs on its tellers is a necessary and effective means to keeping information safe and private.

Identity Privacy

The other and much more publicized area of database privacy is in the content that is availible for public use. This is divided up into two areas, data driven for marketing, and data driven for public records.

  • Targeted Marketing - The first people to take unfair advantage of technology in business are arguably the marketing departments. Through the use of cookies, a company can find and archive to their databases loads of personal information about the visitors to their companies and or client's websites. This is where the waters get muddy, because often the users have no idea that their identities, habits and buying records are being recorded and stored. The real problems with this come when these companies, in an attempt to add extra sources of revenue, start to sell this information to other companies. This is what happened in the cases of Verisign (formerly Network Solutions) and even moreso with the DoubleClick corporation. The nail in the coffin that makes this entire practice so upsetting and angering to the average Joe, is the extreme difficulty in being "opted out" of inclusion into these databases. Also getting removed from any lists a user has been added to can be a wild goose chase of neverending unsubscribe emails.
  • Identity Theft - Just by spending a few minutes and possibly a few dollars on sites like peoplefind one can get to nearly anyone in the US and abroad. The ease with which a malicious person can assume someone's identity both online and in real life can be startling. Most people don't even realize that their names, home telephone numbers and home addresses are already probably populated on several public records search databases across the web. Often times the reason it is so easy to find information is not the fault of the subject of the search. Companies often use very powerful information as the key to customer records, such as a person's social security number or the use of a drivers license number. All of this information once obtained can be used quickly and often unchecked to assume the identity of a person. A hacker by the name Kevin Mitnick has written several articles on the ease with which one can obtain all the details of a person's life from public online databases (one, two).

Ethical Implications of Database Privacy Compromise

  • Who is to blame? Consider a situation where a database protected private data, but there was no attempt to ensure its security except the statement that no one is to misuse it. A person who compromises the database in a misuse fashion has committed an ethical infraction (we are ignoring his/her motives), but isn't the developer who required security but doesn't secure also culpable? What if the developer implemented security, but did it in such a poor fashion that no security was added; is he still culpable?
  • Deontologists and Utilitarians would both agree that the developer is wrong for not completely securing a private database when the techniques used to compromise it are well-known. Utilitarians would argue that since databases must be secured to prevent someone from compromising it and thus committing an ethical wrong, developers have an ethical responsibility to ensure the security of systems they develop where security is a requirement.

Bibliography

Database Privacy Issues


Database Security


Securing a Databases Privacy


Commerce and Private Information


The Government and Privacy


Identity Theft


Source Files

Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC_379:Research_Assignment_Sample&oldid=15809"