Sitelock citing prone SQL injection attack warning

[greinert]

Any suggestion on exactly what I need to fix and how to do it?

====

Sitelock Synopsis: A CGI application hosted on the remote web server is potentially prone to SQL injection attack.

Description: By sending specially crafted parameters to one or more CGI scripts hosted on the remote web server, SiteLock was able to get a very different response, which suggests that it may have been able to modify the behavior of the application and directly access the underlying database.

An attacker may be able to exploit this issue to bypass authentication, read confidential data, modify the remote database, or even take control of the remote operating system.

Note that this script is experimental and may be prone to false positives.

Solution: Modify the affected CGI scripts so that they properly escape arguments.

Technical Details:

Using the GET HTTP method, SiteLock found that :

+ The following resources may be vulnerable to blind SQL injection :

+ The 'rp_subject' parameter of the /index.php/index.php/help/suggestion-about-website CGI :

/index.php/index.php/help/suggestion-about-website?rp_anti_spam_answer=&
rp_message=&rp_email=&rp_subject=)+or+(1=1

-------- output --------
HTTP/1.1 200 OK
-------- vs --------
HTTP/1.1 406 Not Acceptable
------------------------

+ The 'view' parameter of the /index.php CGI :

/index.php?option=com_users&view=remindzzcom_users&view=remindyy

-------- output --------
HTTP/1.1 200 OK
-------- vs --------
HTTP/1.1 500 View not found [name, type, prefix]: remindyy, html, usersView
------------------------

+ The 'view' parameter of the /index.php/index.php/2014 CGI :

/index.php/index.php/2014?month=5&view=archivezz5&view=archiveyy

-------- output --------
HTTP/1.1 200 OK
-------- vs --------
HTTP/1.1 500 View not found [name, type, prefix]: archiveyy, html, contentView
------------------------

+ The 'view' parameter of the /index.php/index.php/index.php/2014 CGI :

/index.php/index.php/index.php/2014?month=5&view=archivezz5&view=archive
yy

-------- output --------
HTTP/1.1 200 OK
-------- vs --------
HTTP/1.1 500 View not found [name, type, prefix]: archiveyy, html, contentView
------------------------

+ The 'filter_order' parameter of the /index.php/index.php/school-info/#######-news-archive CGI :

/index.php/index.php/school-info/########-news-archive?task=&filter_order_D
ir=&limit=5&limitstart=&filter_order=zz&filter_order_Dir=&limit=5&limits
tart=&filter_order=yy

NOTE: Used ####### rather than website name for security.

-------- output --------

[itoctopus]

Lately I'm getting the feeling that Sitelock isn't really a "site lock". We are having more and more websites with Sitelock that were hacked. I'm not sure what it does anymore...

Now, allow me to explain something: Sitelock (and some other tools) try to inject SQL code into any page, and if one returns a response code other than 200, then they suspect that the page is vulnerable - even if the page returns a "forbidden" (403) or "not acceptable" (406). What you should do is to filter out all the parameters on that page (using Joomla's filtering functions) in order to return a clean 200 page.

[pipgraphics]

I have had the same email sent to me and I have no idea what I should do, I have asked Hostgator my host provider and SiteLock but nether are responding. Does anyone have any idea what one should do as I purchased SiteLock to protect my site not simply say theres a problem and give not clear instructions on what the problem is. very frustrating.

[deleted user]

Joomla is designed first to use "non-SEF" URLs, meaning that pages are built primarily using query string options in URLs. Common ones include option (what component to route to), task (an action to perform), view (what view of the component to use), layout (the layout in the component's view to display), format (the response format of the request, i.e. HTML, JSON, etc.), limit (a limit on the number of items to display on pages which show lists), id (the actual item ID you're loading), and Itemid (the menu item ID assigned to that page). Note this list isn't all inclusive; Joomla can use a lot of query variables to do a lot of things under the hood.

Manipulating any of these with query string variables can cause unexpected behaviors. This isn't in itself a security issue and the fact that SiteLock is blindly reporting this as such makes me question their service (an accurate report takes into account an application's structure and the internals of what makes it work).

Joomla and its core components already properly filter the options it knows how to use and correctly raises error pages (which SiteLock is groaning about) when you pass an option that results in Joomla not being able to do something correctly (like an item ID not being found, or a component not supporting a response format).

This isn't to say that all of their reported errors are false positives, each one should be reviewed to ensure there isn't a real security risk involved (that rp_subject report as they said resembles a SQL injection attack, as long as the affected component is correctly filtering that data then you're OK).