View Issue Details

IDProjectCategoryView StatusLast Update
0025908mantisbtsecuritypublic2020-02-06 17:59
ReporterRealityRipple Assigned To 
PrioritynormalSeveritytweakReproducibilityN/A
Status newResolutionopen 
Summary0025908: Block URLs in Public Notes from Anonymous Accounts
Description

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.

TagsNo tags attached.

Relationships

related to 0026071 new Provide the full BugnoteData structure EVENT_BUGNOTE_DATA 

Activities

RealityRipple

RealityRipple

2019-07-08 14:52

reporter   ~0062367

Pull Request of Test Implementation at https://github.com/mantisbt/mantisbt/pull/1525

vboctor

vboctor

2019-07-10 01:49

manager   ~0062374

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 EVENT_BUGNOTE_DATA event, and do one of the following:

  1. block the submission with appropriate error message if it has undesired content (i.e. urls as per your current implementation).
  2. create the note with a temporary message and queue up the real message for approval by someone with appropriate access, once approach update the note with the real text or text updated by the moderator.

Anyways, implementing 1 above should be simple as a plugin.

RealityRipple

RealityRipple

2019-08-22 15:17

reporter   ~0062632

Last edited: 2019-08-22 16:54

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>
However I'd like to wait until the parameter is either decided to be included or not before adding it to the official Plugin list.

dregad

dregad

2019-08-23 05:28

developer   ~0062635

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.

RealityRipple

RealityRipple

2019-08-23 05:33

reporter   ~0062636

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.

dregad

dregad

2019-08-23 06:45

developer   ~0062638

Attached files are probably the only other thing that would potentially be included in notes

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

This is sort of getting off-topic for this report

Indeed. Follow-up in 0026071.