I have a customer whose site has just been hacked using what I suspect to be a XSS attack. The customer claims he uploaded a couple of product pictures through the product section of the admin. A few minutes later, he noticed that the image links in the category section of the site were broken. He inspected the URL and it pointed to another site of some company he had never heard of.
I checked the modification dates of the web site's files on the server and none of them were modified. My guess is that no code was inserted into any of nopCommerce's files. I have seen a similar intrusion before, but the attacker gained entry to an FTP account.
At a complete loss for how it could have happened, I restarted the site via the admin and noted that the image URLs were magically restored. Within a few hours, however, the broken images containing the URL to the other site returned. This time it appeared to only effect the two images my customer had uploaded. The attack isn't specific to a session, it happens across browsers and platforms.
My guess is that the site is being hacked through some kind of XSS scripting that is non-persistent. The code could be lying dormant in some database table, but given the numerous tables and records, it would be like trying to find a needle in a haystack.
Currently, I have a hunch that it is using some Cross-Site Request Forgery or CWE:
http://cwe.mitre.org/data/definitions/352.html
The following link describes a good example of how it can be done:
http://stackoverflow.com/questions/3260744/broken-images-in-xss-attacks
Although I haven't checked, I have a hunch that the session could have been hijacked by not having the HTTPONLY attribute set to true:
https://www.nopcommerce.com/boards/t/19949/sensitive-cookie-missing-httponly-attribute-pci-compliance.aspx
Apparently, this issue was fixed in version 2.7, but since my customer is running 2.5, it's likely that this fix hasn't been implemented.
Can anyone provide suggestions for how the site could be compromised? Can setting HTTPONLY via the web.config solve this issue? How can such an intrusion take place without persisting any code whether through the file system or the database?
Any pointers in the right direction would be greatly appreciated.
Thanks.