JIRA Service Desk Signup misused by spammers

Daniel Himler

Hi!

We are running JIRA Service Desk with public sign-up enabled. This is not what I want but if we disable it, mails by customers without an account are discarded without any notice (I really would like to understand the background of this behavior, because discarding anything but confirmed spam is a no-go and will definitely not raise customer satisfaction).

A few days ago a spammer misused the sign-up function on the customer portal by putting the message content into the name field and the message recipient into the mail address field. This way the welcome mail turned into a spam mail, containing "Hello <spam content>...".

So I disabled the public sign-up and started to search for a solution to the problem like one of the following:

• Disabling public sign-up with the possibility to send a notification to unregistered customers sending a support request via mail instead of discarding the mail silently (requesting them to sign-up before sending a mail would definitely be my preferred solution).
• Disabling public sign-up on the portal (not the whole portal), but still be able to automatically create customer accounts when they send a mail to the support address.
• Enabling the captcha feature until noticing that it is not available for the customer portal. I don't know what the honeypot function that's being used instead is, but it does not seem to work properly.
• Disabling the welcome mail when users sign up via the customer portal.

But NOTHING seems to be a possible solution. I upgraded to version 3.11 when I read about the possibility to disable the "Account verification emails" just to figure out that this option seems to only work for accounts created by requests via mail.

So I enabled public sign-up again and really hope someone can shed some light on the situation for me before it is getting abused again. Maybe I am understanding something wrong, maybe I made a configuration mistake. But to decide between discarding mails from my customers or sending out spam is just unacceptable.

Thanks in advance and kind regards,
Daniel

Craig Castle-Mead_20fp9z

Sounds like we got a similar action around the same time. 

To help minimize this, we implemented a simple nginx rule that seems to be stopping what we don't want to happen, but not impacting anything else

NB: please test in a non-prod environment as this may not be exactly what you need, or, your environment may not be the same as ours

  location "/servicedesk/customer/user/login" {
     rewrite ^ https://$server_name/login.jsp?os_destination=/default.jsp permanent;
  }

 

Should be similar for Apache too

Let us know how you go

 

CCM