[pmwiki-users] [pmwiki-devel] ZAP shopping cart question

Crisses crisses at kinhost.org
Wed Nov 8 15:01:51 CST 2006


On Nov 8, 2006, at 2:47 PM, The Editor wrote:

> Are you talking about a security vulnerability or a poor programmer
> setting it up wrong?  I mean, javascript is not that complicated
> though it is a bit weak on math.  The way my script works, users
> cannot edit the line totals, only the quantity.  And it recalculates
> onblur so you always have the exact total. I could have php calculate
> the total, and may do that first anyway for non Javascript browsers,
> but it would be quite limiting

I'm talking about "security" vulnerability.

If you are a merchant selling things you need to ship out, and you  
check your invoice totals with a calculator, and verify the shipping  
prices, and essentially never trust the computer/PayPal that the  
amount is correct, it doesn't matter.

If you set up a site where anything automated happens -- access to an  
area of the site, or access to a download -- and the payment is never  
checked by a human being, then you're in trouble.

Someone can copy the HTML & javascript form data from your site, then  
re-code the javascript to calculate the transactions differently, as  
an example.  All they need to do is find out what email address the  
payment is being sent to -- which is easy -- initiate a transaction  
to PayPal, then cancel it.  Now they have all the info they need  
since you have JavaScript calculating the shopping cart totals.  Just  
make their own javascript (or form) to send arbitrary values to your  
PHP script, or directly submit the payment.  Since it's all browser- 
side scripting, it has vulnerabilities to people changing your code.   
That's why form validation with only JavaScript doesn't work.  You  
have to validate on the (php) server, or people can get around it.

> Actually, on second thoughts, if the total is changeable you have a
> potential that that value could be forged.  Which suggests it might be
> best to have a preview page, and an actual finalization page.  The
> first could be edited by javascript.  The second would be set in
> stone.  Would that solve the concern you are addressing?  A bit of
> trouble perhaps, but probably worth it.

Yes.  Use JavaScript only to change values for the website viewer  
when they're updating quantities.  Use PHP to calculate the REAL  
shopping cart totals -> submit for payment.

> See my notes above on the possibility of a preview markup, and a
> checkout markup.  The disadvantage is, an admin that wanted to modify
> the price calculation system would have to do it twice--one in
> javascript and one in php, for the two different phases.  Not ideal.
> But agree that for downloads and access fees, it might be necessary.

And so that merchants don't have to sit around with a calculator  
every time they get an order.  We use technology to attempt to save  
us from tedious tasks.

>> Also, if we work with similar mark-ups, if someone wanted to upgrade,
>> it wouldn't be as hard.
>
> I think we are probably talking about pretty different approaches.
> The ZAPcart's markups are next to nothing.  And the item list storage
> is just a single page of lines like (:item: name|cost:).  So, not too
> much I even have available to change.

But I could use a similar mark up, for example.  That would make it  
easier for people to move from one type of cart system to the  
other... it would expand their options, but they wouldn't have to re- 
format everything to switch.  [It's almost like the discussion that  
all database programs should use the same database connection script  
-- it saves time, code, and will be better on the servers once people  
start making very complicated PmWiki->database set-ups]

I'll have to see how you have things worked out to decide.

>> I'm not interested in pay-only sites, but I had a customer who is.
>> What I need is like you said: elevated privileges for a price.  So
>> someone pays and is added to a privileged group with additional
>> access to other features.  When their subscription runs out, PayPal
>> renews them or their access to the privileged group is removed.
>
> I didn't know about this.  I should look into it some more and see if
> there's a way to get that url to update zap stuff.  It seems using
> ZAPget I could get the info from the url, I could construct a zap form
> based on that info, with appropriate conditionals, etc.  And I've
> learned how to trigger a form submission onload by embedding it in a
> gif.  (How the zapcart works).  This could make paypal's notifications
> trigger automatic zap forms to enable whatever you wanted.
>
> Keep me posted if you find more info.  I would be interested in trying
> to set up a snippet for this in zap if you can find out the exact
> spec's on what they send you.

I suggest you sign up for developer.paypal.com -- that gives you  
access to sandbox.paypal.com.  The second site allows you to create  
fake paypal accounts (merchant and buyer) to try out shopping cart  
systems.  the developer site has documentation.

Crisses




More information about the pmwiki-users mailing list