CSC 379:Research Assignment Sample: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
| (9 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
'''''Note: Include the title and path of your page on the [http://ethics.csc.ncsu.edu ethics.csc.ncsu.edu website] at the bottom of your wiki page. Once your wiki page has gone through peer-review and posted to the website, your page's name will be that title. Ex: "Database Privacy" "privacy/database"''''' | |||
= Study Guide = | = 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 = | |||
[http:// | === Database Privacy Issues === | ||
* [http://www.stack.nl/~galactus/remailers/ Anonymity and privacy on the Internet] ''Arnoud "Galactus" Engelfriet'' | |||
* [http://www.inetcon.com/priv.html Ethical implications of email privacy] ''Victoria A. White'' | |||
* [http://www.hackcanada.com/canadian/freedom/canadna.html Canada's DNA Database: Privacy's last stronghold destroyed] ''HackCanada.com'' | |||
[http:// | === Database Security === | ||
* [http://en.wikipedia.org/wiki/SQL What is SQL?] ''wikipedia.org'' | |||
* [http://www.baycongroup.com/sql_command_reference.htm SQL Commands] ''baycongroup.com'' | |||
* [http://www.securiteam.com/securityreviews/5DP0N1P76E.html SQL Injection Walkthrough] ''SecuriTeam.com'' | |||
* [http://www.unixwiz.net/techtips/sql-injection.html SQL Injection by Example] ''Steve Friedl, Unixwiz.net'' | |||
* [http://www.owasp.org/software/labs/phpfilters.html PHP Input Sanitation Filters] ''owasp.org'' | |||
[http:// | === Securing a Databases Privacy === | ||
* [http://www.4guysfromrolla.com/webtech/061902-1.shtml Protecting Yourself From SQL Injection] ''Ross Overstreet'' | |||
* [http://www.windowsitpro.com/Article/ArticleID/42216/42216.html?Ad=1 Protecting Against SQL Injection] ''Umachandar Jayachandran'' | |||
* [http://java.sun.com/docs/books/tutorial/jdbc/basics/prepared.html Using Prepared Statements in Java] ''java.sun.com'' | |||
=== Commerce and Private Information === | |||
* ''Marketing vs Privacy'' | |||
** [http://www.bgassociates.com/essay2.htm Database Privacy] ''Brent Green & Associates, Inc.'' | |||
** [http://www.cio.com/archive/cio_021596_qa.html Privacy versus profit] ''Carol Hildebrand, cio.com'' | |||
** [http://www.tbtf.com/resource/priv-marketing.html Privacy marketing] ''Nick Szabo, Tasty Bits from the Technology Front'' | |||
* [http://www.privacytimes.com/NewWebstories/carder_priv_1_27.htm Specialists: 'Carders' Target Credit Numbers] ''PrivacyTimes.com'' | |||
* ''Lotus Marketplace'' | |||
** [http://www.cpsr.org/dox/conferences/cfp91/culnan.html The Lessons of the Lotus Marketplace] ''Mary J. Culnan'' | |||
* ''P-TRAK'' | |||
** [http://www.news.com/News/Item/0,4,1527,00.html Research service raises privacy fears] ''Rose Aguilar, news.com'' | |||
** [http://www.news.com/News/Item/0,4,1539,00.html Service pulls Social Security numbers] ''Rose Aguilar, news.com'' | |||
=== The Government and Privacy === | |||
* The [http://www.ssa.gov Social Security Administration] Web-site controversy | |||
** [http://www.news.com/News/Item/0,4,9555,00.html Social Security site closed] ''Janet Kornblum, news.com'''''' | |||
** [http://www.cnn.com/TECH/computing/9903/29/secssn.idg/ SEC database exposes Social Security numbers] ''CNN.com'' | |||
* [http://www.eff.org/pub/Privacy/cfp2_convention.summary Computers, Freedom and Privacy - 2: A Report] ''Steve Cisler'' | |||
* [http://www.securityfocus.com/news/142 DEA agent charged with selling data] Kevin Poulsen, ''Security Focus'' | |||
=== Identity Theft === | |||
* [http://www.cs.rutgers.edu/~watrous/people-hunting.html People hunting (on and off the Web)] Donald Watrous, Rutgers University | |||
* [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'' | |||
== Source Files == | |||
'''Title: Database Privacy''' | |||
privacy/database | |||
* [http://ethics.csc.ncsu.edu/privacy/database/study.php '''Original Study Guide'''] | |||
* [http://ethics.csc.ncsu.edu/privacy/database/ '''Original Bibliography'''] | |||
Latest revision as of 13:02, 26 July 2008
Note: Include the title and path of your page on the ethics.csc.ncsu.edu website at the bottom of your wiki page. Once your wiki page has gone through peer-review and posted to the website, your page's name will be that title. Ex: "Database Privacy" "privacy/database"
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
- Anonymity and privacy on the Internet Arnoud "Galactus" Engelfriet
- Ethical implications of email privacy Victoria A. White
- Canada's DNA Database: Privacy's last stronghold destroyed HackCanada.com
Database Security
- What is SQL? wikipedia.org
- SQL Commands baycongroup.com
- SQL Injection Walkthrough SecuriTeam.com
- SQL Injection by Example Steve Friedl, Unixwiz.net
- PHP Input Sanitation Filters owasp.org
Securing a Databases Privacy
- Protecting Yourself From SQL Injection Ross Overstreet
- Protecting Against SQL Injection Umachandar Jayachandran
- Using Prepared Statements in Java java.sun.com
Commerce and Private Information
- Marketing vs Privacy
- Database Privacy Brent Green & Associates, Inc.
- Privacy versus profit Carol Hildebrand, cio.com
- Privacy marketing Nick Szabo, Tasty Bits from the Technology Front
- Specialists: 'Carders' Target Credit Numbers PrivacyTimes.com
- Lotus Marketplace
- The Lessons of the Lotus Marketplace Mary J. Culnan
- P-TRAK
- Research service raises privacy fears Rose Aguilar, news.com
- Service pulls Social Security numbers Rose Aguilar, news.com
The Government and Privacy
- The Social Security Administration Web-site controversy
- Social Security site closed Janet Kornblum, news.com'
- SEC database exposes Social Security numbers CNN.com
- Computers, Freedom and Privacy - 2: A Report Steve Cisler
- DEA agent charged with selling data Kevin Poulsen, Security Focus
Identity Theft
- People hunting (on and off the Web) Donald Watrous, Rutgers University
- Fighting the Plague of Identity Theft CNN
- Stomp the identity thieves Kevin Mitnick, TheRegister.co.uk
Source Files
Title: Database Privacy
privacy/database