Announcement

**kev67** · 30-Sep-2015, 05:05 PM

This is correct from SD, although a bit of a sarcastic and non-helpful reply, but it's actually true if the website was fine before

"The software does not use SQL online or offline so there is no opportunity to add anything, the software uses Perl on the server.

I can only recommend that if your hosting company has no way to obviate the problem that they have caused, then you must seek another hosting company and use them."

This is a pretty common error as I've had this before many times and it's basically down to the SD software not communicating with your server where your website is hosted

Unless someone will state differently of course

Quote

"It does look like your files are being blocked by the servers security settings. Unfortunately it's being blocked due to it detecting a SQL Tautology Injection attack"

WTF is the above about?

SD does not use SQL for a start. And even if they did, then it's down to your hosting provider to sort this out, not you

The above explanation from your hosting company is unbelievable and a cop out

It took me over a week to get an answer from my previous host supplier as to why my website was running slow. According to the them, it was my CGI-bin folder being used to send spam mail

Their one week later TECHNICAL SUPPORT TICKET reply was that my virtual server is old ! and I should order a new version......

But from the sounds of it, as you say
"this was last Monday and have been unable to download orders since until today", then it's now working and your host provider has done something?

**tristam** · 30-Sep-2015, 07:28 PM

I have just had another response from them

I have looked over my colleagues notes and it appears to be the Actinic system that is being probed with SQL injections. Unfortunately any system is exploitable given enough time which is why as soon as an exploit is discovered the producers of the software fix the weakness and release an update. With websites being public facing they of course provide a larger target for access then your personal computer and so it is as important if not even more so that all aspects of a website are kept up to date at all times. I personally check for updates on my site software on a weekly basis to ensure they are fully updated and secure. If your system is not fully updated then someone could indeed presently be trying to exploit your site. however it is for this reason that we have the security measures in place that block access to the source of the exploit attempt to help provide our customers with an additional layer of security.

**tristam** · 30-Sep-2015, 08:05 PM

Just told them SD doesn't use SQL and they say

Is the software up to date? If not then this requires updating. The SQL injection is being targeted at the site and appears to be coming from this package which may be being inserted via perl if you have any entry point however regardless of the presence or lack there of of a database to attack (in this case your site does not use one) it can still be detected as an attempt at a hack which is why it was blocked. A potential hacker does not know that you are not using a database and will simply "try their luck" often in this sort of situation.

**Mike Hughes** · 01-Oct-2015, 07:52 AM

From what I can tell it sounds as if a hacker is trying to break into your site using an SQL injection attack. It won't do anything as you aren't using an SQL database but I can quite understand some sort of security software recognising the attack and taking action to block the source script.

I can really only see three options open to you.

1. Limit the attack. You have no control of the attacker but you might be able to block their IP address if fixed. Another option would be to work with your host and Sellerdeck in order to find the route that the attack is taking to get into the system and closing the hole.

This is probably the 'correct' option but will take time and effort.

2. Limit the impact of the the attack. Get your host to change the security settings on your server so they don't impact the proper running of sellerdeck.

I think this is unlikely as server hosts are always unhappy about easing up on security.

3. Move host. This should be fairly quick and easy and should solve the problem as long as the new host isn't using the same security software that is causing the problem. A UNIX server might be a good idea.

As a quick fix you could try changing the script numbers and doing a site update. This should get you going long enough to download orders before the security software decides the new script is also a problem. If the SQL injection attack has gone away then this might even fix your problems for good.

Mike

Announcement

Problem retrieving orders

Problem retrieving orders

Comment

Comment

Comment

Comment