Author |
Topic |
|
yhcab
Starting Member
2 Posts |
Posted - March 13 2004 : 15:18:14
|
I am a prospective buyer of this product, and an experienced amateur ASP programmer myself. As I understood, the foundation of security in such an application is the session. Before any administrative script in a product like VP-ASP would do anything, it would perform two tests:
1) is there a session, indicated by the presence of a session cookie issued by the server and fairly hard to guess 2) if yes to (1), was there a successful login previously in this session. This might be determined by checking if some session variable like session("adminLoggedIN") = true
Hacker scripts like the Indonesian "SQL insertion" gem in another thread here would not pass the first test as written. A bit more work would be needed before requests fired at the server by a perl script would match a session.
Such scripts would never pass the second test, unless the hacker had already logged in, in which case he probably wouldn't bother with the script anyway.
So I am confused -- how could the SQL insertion attack ever have worked? Or does VP-ASP not use the session for security? If not, would it be hard to modify to perform the sort of tests described above?
|
|
support
Administrator
4679 Posts |
Posted - March 13 2004 : 16:57:33
|
All our admin pages are protected by admin session checks. That has never been an issue.
Security is reasonably hard to accomplish with an open source product but we believe we have achieved it with VP-ASP. Even Microsoft which totally hides its underlying software has has numerous "security holes".
SQL injection comes about when you allow humans to enter data. This is primarily on query strings such as catalogid or a categoryid. The hacker uses this tiny opening and adds their own SQL to the query string. Some database but not all, allow this extra SQL to execute which results in the data insertion. Access does not allow these extra SQL to execute but SQL Server and MYSQL do. We believe we have closed all these possible hacker holes but we are always vigilant and if any are known, we welcome feedback.
Even after an SQL injection attack, VP-ASP allows you to hide the admin system. So in most cases the attack is worthless since the hacker cannot find out where to login. VP-ASP also provides dual locks. One of these locks is only known to the merchant. So even if the hacker found the admin system, they would not know the second password lock.
VP-ASP Support
|
|
|
yhcab
Starting Member
2 Posts |
Posted - March 13 2004 : 17:51:56
|
OK, I understand ... this was not in the administrative section. This was in the public section, where request data from the client was originally not checked for appropriate form before being used to build SQL queries.
To be secure, this application must check every value supplied from the client, whether part of a query string or posted from a form, to make sure it has the proper type, or in the case of text to be inserted in the database, to to make sure single quotes within the text are doubled.
Security notes indicate that known holes have been plugged. But has the application been thoroughly scrubbed in this way? All the way to the end of the checkout, and all side functions such as checking order status?
|
|
|
support
Administrator
4679 Posts |
Posted - March 13 2004 : 18:34:20
|
I can only say we have no known holes. We ourselves are under attack 365 days a year and we follow the same rules we recommend to our customers and use the same software.
VP-ASP Support
|
|
|
siraj
VP-CART New User
USA
194 Posts |
Posted - March 13 2004 : 22:18:57
|
Its easy to say, what could have been done, but whatever you do, there are freek out crack you, not even microsoft cant keep up with securtiy and every other day relasing patches. VP-ASP has set of security procedures and if merchants follow that, they could minimize the hazard or keep the hackers away. If you are a developer, you can do number things to keep the hackers away and even you can changes the database user table name and change appropriate/ assoiciated files and settings. GOOD LUCK.
SJ.
[email protected] |
|
|
|
Topic |
|