Number 12 on your list, is something I mentioned before. What happened is that once upon a time the creators of super orders decided that they wouldn't filter any data going into the database so on a batch they would go "SHOW ORDERS WITH A VALUE <= 200" and they have in that select box "<=".

HTML code begins with < and in my particular field of knowledge

http://www.theregister.co.uk/2009/08...mail_xss_flaw/

you can do seriously dangerous things with unfiltered data and a <script> tag. One of the version of zencart 1.3.7 (I think), DrByte put in some cod that translates anything coming through as "<=" into html "&lt;=" to protect from having malicious code injected into the website. That broke that part of super orders. A lot of the data in zencart is filtered now, but super orders doesn't so for exampled <script src="badguy.com" /> could be put into an address field, the website administrator would look at the order and not see anything because browsers don't display HTML tags to the user. The bad guy could then steal user data, in theory hijack the adminsitrators session, go in change the password and lock them out and steall all the credit card details and inject code into the database that would display pronorgraphic adverts (that's very very easy). All because the design of super orders is old "rubbish".

The ZC team have done an excellent job in filtering data all over the place, but the fundamental code underneath super orders is very flawed. The security problems are all over the whole set of pages, too many to list. But not only are there the XSS problems (that's what I just described) but there is also the possiblity that a malicious customer could inject code into the database from something like the payment details field combined with another module, because super orders does not do any filtering of the data it looks for in the database. Which would be the same result as described above, if the adminisitrators session was hijacked.

ZC does have additional security measures in place to stop session hijacking, they filter a lot of the data, if not all of the input. But they still can't do anything about porrly written add-ons from the days when attacks were theoretical rather than everyday. I'm not actually a hacker, I spend some time in the forums and I know some techniques, but most of the time I am repairing the damage done by 15 year old vandals who hijack a server and then don't know what to do with it.

The batch processing code in super_orders is really quite unusual someone had a strange idea that may be on the far edge of genius (seriously) because to get it to work is stunning as it uses insane code that is preposterous, it's also really dangerous to explore the possibility of being able to include a batch file a hundred times to do a job, because if some hijacked of altered that file then you have a page that could launch a denial of service attack that your clients wouldn't even know about.

There are just so many things wrong with the module that it needs a total rewrite, I just don't have the time what with the other modules and work to do.

Philip.