|
sanitize
the data you entered, meaning
that they will check for characters that don’t belong. For example, if the web
form required you to enter your telephone number, properly sanitized data would
generate a secure error message if you entered special characters into the field
instead of numbers. You simply can’t call the number “867-530(“. The open
parenthesis character doesn’t belong in the phone number field, so you wouldn’t
be allowed to proceed with the registration process until you enter valid
characters.
But here’s where the trouble begins. If the developer made an error in their code
that doesn’t properly sanitize the data, a hacker could insert (i.e.
inject
) text into
the web form field that completely changes the operation of the SQL statement.
By placing SQL code into the web form, the attacker has the ability to disrupt
the database because their text and characters would be plugged directly into the
SQL commands.
But how do you determine if a web form contains the potential for a hacker to
inject their own malicious code into the SQL database in the first place? It all
comes down to viewing the error messages displayed after trying to input data
into a field. For example, one thing you can do to test this is to surround the data
you type into a web form field with double quotes. More often than not, if an
error message appears, this is a good sign that you can successfully inject code
into the SQL system. In rarer cases, the form might display a buggy-looking
blank screen. In this event, the database may or may not be injectable. When this
happens, hackers use a process called blind SQL injection because they can’t
directly see what impact their injected code had on the database. If neither of
these things occur, then it is highly likely that the website isn’t vulnerable to
SQL injection.
If it has been determined that a website is indeed susceptible to SQL injection,
the following is code an attacker could inject into the background SQL code to
facilitate the attack:
-
“OR 1=1“
This code is problematic for the website because it will always cause a statement
to evaluate to TRUE and trump any logic statements coded into the intended
command. For example, consider a command that was intended to update a field
if conditional criteria were met. The intent of the command may have been to go
through the database, find the user Peter Gibbons, and update his credit card
number. As the database goes through each entry, it will evaluate the value of
the user field and only make changes on records that contain a user with the
name of Peter Gibbons. Any name that doesn’t match “Peter Gibbons” would
evaluate to false, and those records’ credit card numbers wouldn’t be updated.
However, when the “OR 1=1“ command is applied to the logic statement, things
start to break down.
OR statements always evaluate to TRUE if one or both of the expressions on
either side of the OR statement evaluate to TRUE. So in this example,
all
of the
records in the database would evaluate to true because 1=1 is a true statement.
The net effect is that all of the users’ credit card information would be
overwritten with bogus data. Though it is highly likely that older copies of the
database were created for a backup, this attack creates a massive problem. In the
blink of an eye, a hacker just effectively erased all of the credit card information
out of the currently active database and the company is screwed. Furthermore, if
new data was entered into the database but that information hasn’t been backed
up yet, that data is gone forever. But this is just one example.
Using these types of injection techniques, hackers can do the following:
-
Delete sensitive information
-
Escalate their privileges in the website
-
Create new administrative accounts
-
Steal usernames and passwords
-
Steal payment card data
-
Garner complete control over a database
However, remember that hackers can’t do these things to every database. They
can only perform these tasks on websites that are vulnerable to SQLi attacks.
Cross-Site Scripting Techniques (XSS)
If you’re not a techy or you haven’t had any exposure to website design, you
probably haven’t heard of XSS before. But XSS attacks aren’t anything new. In
fact, they have been used and abused since the 1990’s. But the variety of ways
that XSS attacks cab be performed far outnumber SQLi attacks. For that reason,
XSS is a much more flexible technique and it can be used to inject malicious
code into a user’s web browser or even take over a session between a client and
a server. To top it all off, a hacker doesn’t need to manually initiate the attack.
Instead, it can all be carried out automatically. You would think that because
these types of attacks are so old that their use and frequency would be waning,
but that just isn’t the case. Because of this, many white hat security professionals
view XSS attacks as the bane of their existence. Sadly enough, they can be easily
prevented but too many people fail to take adequate measures to protect
themselves.
XSS Details and Web Browsers
Web browser technologies have been rapidly accelerating over the past 5 years,
and they offer a ton of valuable software that is unprecedented in the Internet
age. When you compare them to older browsers such as Netscape, the
technologies they offer today seem truly staggering. However, all of the extra
features and technologies that have been added to web browsers over the past
decade have increased the opportunities for XSS hacks. The flaw all stems from
a web browser running a script.
HTML (Hyper Test Markup Language) is the most popular tool for formatting
web content to date. By using tags in the code, HTML is able to change the
appearance of data on web sites. The problem is a troublesome tag that allows
websites to embed scripts. When your web browser encounters the Do'stlaringiz bilan baham: |
