View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0025908||mantisbt||security||public||2019-07-08 14:48||2020-02-06 17:59|
|Summary||0025908: Block URLs in Public Notes from Anonymous Accounts|
If an anonymous account is required, for, say, automated reporting by software, or just because you'd rather not prompt your users to create an (or another) account, there should probably be some extra spam prevention methods added in. My suggestion is simple: block the anonymous account from sending Notes with URLs in them.
Private notes probably aren't a big deal, since spammers are unlikely to target a single person. If this changes in the future, it can easily be changed, however. But for now, it makes for a good alternate way for legitimate anonymous users to post URLs in notes if necessary.
I've created a quick and dirty test implementation based on a dead-simple algorithm I've been using on my own website for years. Changes are very welcome.
|Tags||No tags attached.|
Pull Request of Test Implementation at https://github.com/mantisbt/mantisbt/pull/1525
Thanks @RealityRipple for your contribution.
I'm generally not convinced that allowing anonymous user to contribute content is a good setup. There is obviously the spam risk, but there are also the fact that it is not a setup that allows for collaboration with the user who submitted the issue or even have some pseudo identity for them to know who said what.
The antispam work was mainly don't for providing some very basic protection for users that signup and then contribute content.
Given the above and that that the suggested anti-spam work in this PR is content based, I was wondering if it would be better to implement this as a plugin that can hook into
Anyways, implementing 1 above should be simple as a plugin.
EVENT_BUGNOTE_DATA does not currently pass along $p_private - any chance that can be added as a parameter?
Edit: I put together a plugin that can, but doesn't have to, support $p_private: <https://github.com/RealityRipple/SafeAnon>
I have no objections with adding the view status to the EVENT_BUGNOTE_DATA event, but I'm wondering if we should not send the whole BugnoteData structure to the event, instead of just the text, the bug_id and now the view_status... what would come next ?
This would be consistent with what we do in EVENT_BUG_DATA. Of course such change would break backwards compatibility for existing plugins relying on this event.
Attached files are probably the only other thing that would potentially be included in notes. This is sort of getting off-topic for this report, though, and should probably be started as an additional issue.
Not sure if you're aware that attachments are currently not directly linked to bugnotes, but to the parent bug instead. The relationship to the note is inferred based on timestamp. This should be fixed in the near future (see 0021733), so at this time this is probably not feasible. I have not looked in detailed at the proposed implementation
Indeed. Follow-up in 0026071.