TomatoCart

There are some serious exploits shown here
www.exploit-db.com/exploits/14330/

What do you think about it? Is tomatoCart shop insecure?

EDIT: I tested the change password one and it worked, so I suppose all work. The admin has to be logged in for them to work though. What someone can do then is to use these HTML codes on another website, and when the admin of the specific tomatocart visits this evil site, well, then they WILL WORK!

A way to prevent them from working is to check the referer and require it to be the tomatocart site.

xonium wrote:
EDIT: I tested the change password one and it worked, so I suppose all work. The admin has to be logged in for them to work though. What someone can do then is to use these HTML codes on another website, and when the admin of the specific tomatocart visits this evil site, well, then they WILL WORK!

A way to prevent them from working is to check the referer and require it to be the tomatocart site.

These things currently only work when you are logged in as administrator.

In the JSON server side parser there os the following line:



So if you aren't logged in into the admin you can't execute the calls. If you want to do this u first have to do a session hijacking.

But good that people are posting possible security leaks (better than keeping it in the underground), and I hope the team takes them very seriously and puts effort in security.

xonium wrote:

A way to prevent them from working is to check the referer and require it to be the tomatocart site.

NO! Do not do this as the security check. A referring URL is easily spoofed. How to Spoof a Referrer

Here is the proper way to do it: Create a CSRF Token (Just the PHP one...not the Zend framework one)

Brief summary: When you load a page with a form that gets submitted to json.php you create a unique token - preferably something cryptographically secure and at least psuedo-random. Store this value in the session ($_SESSION['csrf'], perhaps?). On the form you add a hidden field and also put the token information. At this point they should match.

When you submit the form to json.php, json.php will check the $_SESSION['csrf'] value and compare it to the form value that is submitted along with the form. If they do not match, then something funky is going on here. If they match, proceed with the rest of the logic.

A very quick check of the source shows that there are at least 52 files that reference json.php in some way

You guys don't seem to fully understand the attack.

You don't really need to hijack the session, it's not the evil guy that are executing the attacks directly. The evil guy puts up a website with these codes for example. He sends an email to the victim, the admin of a specific tomatocart site, the victim visits the website and if the victim is logged in as admin to his tomatocart site, it's the victim itself who executes these codes. And in this case a referer check IS a protection. You can spoof your own referer, not someone elses!

Ok I figured a little and MooMoos solution would be the best!

A referer check would work, if not like now, you can read emails inside the admin interface.
That's very dangerous as you could put these codes then right there in the email and if the admin then supports HTML emails, I don't know as I haven't tested, well then the code will be executed and the correct referer would be set so in this case it's correct that referer check isn't a protection.