Hi, we have a pretty simple form that requires a few text fields (name) and email ..we use the recaptcha and I as a human can not submit the form until the correct captch code is entered.
Is there anything we should do to ensure any sort of injection? Thanks in advance for your all's review.
Following is the email used to notify staff of an inquiry: (maybe one or two a week)
Is there anything we should do to ensure any sort of injection? Thanks in advance for your all's review.
Following is the email used to notify staff of an inquiry: (maybe one or two a week)
Petovichs Petovichs has made an online advertising inquiry. Please review the following information with the appropriate Colombia Reports staff member.
A response to the customer is required within one (1) business day
Customer Information:
Petovichs Petovichs
Email: rolovers@yandex.ru
Tele:
Basic Ad Information From Customer:
Customer Comments: Вы пропустили еще тот факт, что Блог можно использовать как средство для нишевых продаж и извлечения дохода.
Hi el patron,
As long as you use the Joomla JRequest filters when you process any data you should be protected against most injections. Using the raw $_POST entries might leave you exposed.
Bob
As long as you use the Joomla JRequest filters when you process any data you should be protected against most injections. Using the raw $_POST entries might leave you exposed.
Bob
Hi,
Unfortunately, not even captchas are perfect when it comes to stopping spammers. In essence, it's just a way to try and tell man from machine. It does help, as it means spammers must put more effort to get their cr*p through. However, there are shady corporations out there making business selling "de-captcha" services, either by having staff decoding captchas in realtime, or by having sites rewarding the visitor by solving captchas (taken from their clients attempted spamposts).
One thing I personally found useful, is to use different DNSBL (dns blacklists) available and similar services. On a community site I ran, I had a nice system plugin named "Http:BL", which is linked against the Honey Pot Project (http://www.projecthoneypot.org/httpbl.php). Since the service is based on honeypots normal visitors would not touch, false positives are rare, while form/forum crawlers tend to post here (as they like to post to anything resembling a form) and get spotted.
I guess this is starting to sound like an Infomercial regarding the project and the plugin, so I'll stop here...
A few final words though, there are many different techniques as to stomping spam. No single one will cover any case, but combining different variatons and methods usually catch most of it. Captcha/reCaptcha is a good start, you can use the ServerSide Validation of ChronoForms to add additional checks; perhaps see if there's an http:// URI within a message that should not have one, if a message has cryllic letters when you only expect english visitors, (excessive) Use of "BBcodes", blacklists of emails, etc, etc.
/Fredrik
Unfortunately, not even captchas are perfect when it comes to stopping spammers. In essence, it's just a way to try and tell man from machine. It does help, as it means spammers must put more effort to get their cr*p through. However, there are shady corporations out there making business selling "de-captcha" services, either by having staff decoding captchas in realtime, or by having sites rewarding the visitor by solving captchas (taken from their clients attempted spamposts).
One thing I personally found useful, is to use different DNSBL (dns blacklists) available and similar services. On a community site I ran, I had a nice system plugin named "Http:BL", which is linked against the Honey Pot Project (http://www.projecthoneypot.org/httpbl.php). Since the service is based on honeypots normal visitors would not touch, false positives are rare, while form/forum crawlers tend to post here (as they like to post to anything resembling a form) and get spotted.
I guess this is starting to sound like an Infomercial regarding the project and the plugin, so I'll stop here...
A few final words though, there are many different techniques as to stomping spam. No single one will cover any case, but combining different variatons and methods usually catch most of it. Captcha/reCaptcha is a good start, you can use the ServerSide Validation of ChronoForms to add additional checks; perhaps see if there's an http:// URI within a message that should not have one, if a message has cryllic letters when you only expect english visitors, (excessive) Use of "BBcodes", blacklists of emails, etc, etc.
/Fredrik
@nml375 Thanks for your most informative post.
Curious as to whether or not CF uses mysql_real_escape_string or something of that sort to read the post/get submit.
Curious as to whether or not CF uses mysql_real_escape_string or something of that sort to read the post/get submit.
Hi,
mysql_real_escape_string is used with a given set of methods in the JDatabase and JTable classes, not with methods related to reading GET or POST. This is mainly because SQL escaping has no real meaning outside a database context.
CF uses a custom JTable object whenever it stores data using the DB Connection. This means that the escaping is handled by the Joomla API (and it is done properly). In that context, there is no need to worry about SQL code injection. If you implement your own database code in the "On submit" entries, proper caution would have to be taken to provide escaping.
Using the JRequest::getXXX methods does allow for further (optional) filtering, such as to prevent HTML-injection. There is no SQL-escaping/filtering here however. CF does not make use of any extended filtering here, as there could be a good reason for html-formatted form inputs.
/Fredrik
mysql_real_escape_string is used with a given set of methods in the JDatabase and JTable classes, not with methods related to reading GET or POST. This is mainly because SQL escaping has no real meaning outside a database context.
CF uses a custom JTable object whenever it stores data using the DB Connection. This means that the escaping is handled by the Joomla API (and it is done properly). In that context, there is no need to worry about SQL code injection. If you implement your own database code in the "On submit" entries, proper caution would have to be taken to provide escaping.
Using the JRequest::getXXX methods does allow for further (optional) filtering, such as to prevent HTML-injection. There is no SQL-escaping/filtering here however. CF does not make use of any extended filtering here, as there could be a good reason for html-formatted form inputs.
/Fredrik
This topic is locked and no more replies can be posted.
