View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 1808 | Composr | core | public | 2015-02-16 15:25 | 2015-11-07 22:40 |
| Reporter | Chris Graham | Assigned To | Chris Graham | ||
| Priority | normal | Severity | feature | ||
| Status | resolved | Resolution | fixed | ||
| Summary | 1808: Include source IP in error mails | ||||
| Description | Error mails may actually highlight a hacker/bot, so knowing the source IP will be useful. Note that if the error email is auto-sent to ocProducts we should not have the IP in that version, as this would be a privacy violation. | ||||
| Tags | Type: Security | ||||
| Attach Tags | |||||
| Time estimation (hours) | 1.5 | ||||
| Sponsorship open | |||||
|
|
Despite the v10 freeze, is it possible to still incorporate this? This issue is now a major problem. I'm getting floods of error emails regarding someone trying to access a PHP file that has some SQL code injection attempt in it. Depending on my finances, I'll sponsor it, but sadly I can't guarantee it. But I feel this is a big security issue now. |
|
|
You could look in your raw server access logs to find the IP address, as presumably the attack is in a GET parameter and thus would be in there against the IP. It's unlikely someone is actively trying to hack, more likely it's just a dum bot, which will be going over potentially millions of sites looking for common vulnerabilities. If the mails themselves are a nuisance, just set up a simple mail filter rule to auto-delete them. |
|
|
I forgot to mention, sadly I don't have access to access logs on my service provider. |
|
|
Oh that sucks. That's a very unusual situation, are you completely sure? Usually you can get to them some way through FTP. Maybe it's private hosting? Here's a super-fudge. sources/failure.php mail_wrap(do_lang('ERROR_OCCURRED_SUBJECT',get_page_name(),NULL,NULL,get_site_default_lang()).' '.cms_version_pretty(),$mail,array($agency_email_address),'','','',3,NULL,true,NULL,true); --> mail_wrap(do_lang('ERROR_OCCURRED_SUBJECT',get_page_name(),NULL,NULL,get_site_default_lang()).' '.cms_version_pretty(),$mail.get_ip_address(),array($agency_email_address),'','','',3,NULL,true,NULL,true); I just dumped the IP on the end of the mail |
|
|
Yep I'm quite sure. There's no access logs in my control panel, and no access.log file or anything of the like in FTP. I'm with OVH's "shared" hosting (I quote "shared" because in reality it acts similar to virtual hosting, except no root access or anything. You're on the same server as others, but you have dedicated RAM and CPU.) |
|
|
Also I use daily digests instead of instant emails for errors due to the 300 mails / hour limit. Is there any way an IP column or something can be made in Composr's error logs similar to the security log? |
|
|
I was about to say my fudge would work for digests, but actually I got it wrong, I targeted something else. Do this in same file: dispatch_notification($notification_type,NULL,do_lang('ERROR_OCCURRED_SUBJECT',get_page_name(),NULL,NULL,get_site_default_lang()),$mail,NULL,A_FROM_SYSTEM_PRIVILEGED); --> dispatch_notification($notification_type,NULL,do_lang('ERROR_OCCURRED_SUBJECT',get_page_name(),NULL,NULL,get_site_default_lang()),$mail.get_ip_address(),NULL,A_FROM_SYSTEM_PRIVILEGED); This change should work regardless of notification type, as that's just a matter of how they are collected/sent. Doing it for the error log would be possible but it'd be a different part of the code, and not retroactive. It'd be harder though because with a change in the logging format kicking in retroactively it wouldn't know how to column it, unless we do it with care. Not something I can do in a "super-fudge" ;) |
|
|
Alright thanks Chris. I'll see how it works. I see your point regarding retroactivity. |
|
|
Hi Chris. Your super-fudge worked great! I get IPs in the error emails and was able to ban the bot that kept injecting SQL into GET. I have not had another request like that in over a week now ^^ |
|
|
:thumbsup: |
