|
|
Index |
|
|
|
|
|
Database Security Study Guide
Database |
Old Table of Contents
Old 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.
Index of Topics -
Study Guide - Old Page -
Description
|
|
|
|
|