lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date: 20 Jul 2006 00:16:20 -0000
From: contact@...ommerce.com
To: bugtraq@...urityfocus.com
Subject: Re: AFCommerce Shopping Cart

Hi, thank you for reporting this problem. I am Paul, the author of the software, so I would like to do everything possible to correct this issue. The free version of my software is not open source, and not that the encryption is protecting it very well, I'm sure a good hacker could crack the encryption, but the point is to not let the security features be readable to everyone, so hopefully it will lessen problems like this. 

Ok, so with that said, I tested the classic 'or 1=1 on my demo store, and nothing was returned. It said no matching results, so are you sure this worked for you ? I know I am not perfect in any way so I will always look in to this stuff, but when I first read your post I was confused because I attacked my own site for hours checking for that exact kind of attack. 

I don't like to publicly post too much info about how and why I set things up, as to not give anyone any ideas on how to attack my software, but the search feature (I thought) would not be attackable. Now since you did it already, I may be wrong, but I do not use the keywords inside the sql statement. For example, I do not use anything like: select * from products where name = 'userinputvariable'. I have some security functions set up to clean user input, if you know the software, its afc_secure_string_POST. In the search script, I use that function for all input EXCEPT the keywords, but that is because the keywords are not used at all in sql statements (actually none of the input is). Basically, I break the keywords down in to separate words (explode by spaces), then I do my own sql select statements (without any user input at all) and simply check to see if the words match. There is more to my search than that, but for this topic that is all that matters. So if someone were
  to type in any sql injection code, that code would never be queried. Your 'or 1=1 would simply be stored in an array, in your example it would consider it 2 different words (if you didn't use the space it would be one keyword), but the only time that word would be used is in a substr_count statement, which can not do any damage. If this problem does exist, please report back what i am missing from your comment, but since it did not work for me just now, and also since the keywords never hit an sql statement, at this point I will disagree with you. Also make sure you did this on my current demo store, which uses version 2.5. I know that version 1 sucked as far as validation was concerned. I first released the code just to see if anyone would use it, so it was done quickly, but after I had a small following, I added a whole bunch of security features in version 2, and validated EVERYTHING (I hope). Feel free to mess with my demo store, http://crinicart.com , just please do no
 t attack my server or do any damage. As for now, I see your comments as helping the project find holes, which is great, I do want it to be perfect. So if you find something I will be more than willing to listen, just please do not do any damage to prove a point. Its not necessary since I will try out anything that comes up.

Your second point about the reviews, I am about to test that now. With this, you are probably correct. I had more validation in there, but people complain when I did that because they couldn't add html. I though text only was fine, but I wanted to make people happy. I am probably going to take out all < and > symbols. It does check for normal php tags, but I guess someone could still use a script html tag for php attacks. So since it currently allows html I agree someone could deface the site, but only when reading the attacked review, and since most users do not use that feature, I didn't see it as a big deal. Also, the review is escaped with mysql_real_escape_string and a few other things. the only way this could be perfect is to strip all html tags, and that was already in my mind to do.

I'd like to hear what you think, as well as, anyone else with an opinion about your comments (and mine). If a problem is found, it will be fixed the next day, but its tough to be the only developer of software used by many people because I get all kinds of developers telling me something is written poorly just to feel better about themselves. You sound like you know what you are talking about, so I took your comments seriously. If you are correct, like I said I will fix it and thank you. If you are not, I would like to clear it up so my users do not become scared, or hurt my creditibility.

Thank you,
Paul Crinigan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ