A few questions.

[Corey]

Hey guys,

I just have a few questions. When users submit a new ticket, where do they get their support ticket ID at, by email? Wouldn't it be easier to just tell them the information right after the ticket is created?

Username,

Thank you for contacting us.

A support ticket request has been created and a representative will be getting back to you shortly if necessary. Below is your login details to check the status of the ticket.

Login Details
Email: user@yahoo.com
Ticket ID #: 601823

This information has also been emailed to you at the address provided.

Thank you,
Site name Support Team

Unless there is already a feature like this, or a setting I have to turn on I just haven't seen.

Thanks,
Corey

[peter]

That would be a serious security flaw. For example to access all your tickets, all I need to know is your email address to open a new ticket and login. i.e osTicket uses email/ticketID combination for logins. The plan is to move to username/password in the future but still allow email/ticketID to view individual ticket.

[Corey]

That would be a serious security flaw. For example to access all your tickets, all I need to know is your email address to open a new ticket and login. i.e osTicket uses email/ticketID combination for logins. The plan is to move to username/password in the future but still allow email/ticketID to view individual ticket.

I think you misunderstood what I was asking. I was asking wouldn't it be easier to that person the information right after the ticket is created. After searching around I found what I needed.

[peter]

I understood you question!

Yes it would be easier but it will also create a security flaw. Ticket ID is sent to the email as part of email verification. As I mentioned, osTicket uses ticketID/email for logins i.e ticketID is the password. Showing the ticketID is like displaying your possword to anyone who pretends to be you and in turn giving out access to ALL your tickets.

For example...I can open a ticket using your email corey@yourdomain.com get ticketID then simply login and access all your tickets!

[Corey]

I understood you question!

Yes it would be easier but it will also create a security flaw. Ticket ID is sent to the email as part of email verification. As I mentioned, osTicket uses ticketID/email for logins i.e ticketID is the password. Showing the ticketID is like displaying your possword to anyone who pretends to be you and in turn giving out access to ALL your tickets.

For example...I can open a ticket using your email corey@yourdomain.com get ticketID then simply login and access all your tickets!

I'm not asking it would be easier to just use the email. The ticket ID and email is fine, I was asking wouldn't it be easier to tell that person right after the ticket is created the ID. After searching around I found out it's possible to do with messing with the configuration. It was just a setting I didn't see.

Thanks,
Corey

[peter]

I'm not asking it would be easier to just use the email. The ticket ID and email is fine, I was asking wouldn't it be easier to tell that person right after the ticket is created the ID.Neither did I take your question to mean using email alone. If by "tell" you mean email the ticketID as part of auto response, then we are on the same page. My point was ticketID needs to be emailed to the user and not shown as part of 'Thank you' message. Your initial post gave me the impression that you wanted it shown to the user .. see the quoted text.

For the record, osTicket has no setting to display the ticket ID to the user opening a ticket. It is sent via email if auto response is enabled.

[larry_rma82]

Is the security flaw in the visual display of the ticket number and email address on the same page? Or, that the ticket number and email address is included in the same stream of data?

If the visual display is a problem, then maybe a part of the email address can be obscured, since the user knows what their email address is.

Note that the text input object for the Ticket# on the main page is not a password style input object, so any ticket number typed into the field is not obscured by ***** . Thus the pair are vulnerable to the same over-the-shoulder spying as putting the ticket number on the "thank you" page.

If it is the pairing of the ticket number and the email address in the data stream - well, the URL in the Support Ticket Opened email includes the email address and ticket number all together, GET-style.

[peter]

It is not about over the shoulder issue. The two are not even related. I know at first glance the flaw is not obvious, you have to think in terms of the whole system. Ticket ID is sent to the email address as part of verification process. Displaying the ID breaks the process.

If you display the ticket ID, what is to prevent someone else who happen to know your email address from opening a new ticket using your email (Get ticketID) and simply login to access all your ticket?? :confused:

[larry_rma82]

... If you display the ticket ID, what is to prevent someone else who happen to know your email address from opening a new ticket using your email (Get ticketID) and simply login to access all your ticket?? :confused:

I have just tried this test:

1. Using an email address that has previously been entered into the system, I created a new ticket, with nearly completely different information for the other fields, including a different full name.

2. I submitted the form, and I received a brand new ticket number.

3. I used the same email address and the new ticket number to log into the system (via from the main page login, and also via the emailed url).

4. What I was presented with was a list of all the tickets opened with that email address, and I can read every one.

So - the problem is the bad guy getting a user's email address. Having an existing ticket number is irrelevant, because the bad guy can create a bogus new ticket, get a new ticket number, and use that to log in and see all the submitted tickets for that email address.

I do thank you for leading me to this realization. I'll try to implement some security to block this type of attack while a username/password scheme is being created.

[peter]

So - the problem is the bad guy getting a user's email address. Having an existing ticket number is irrelevant, because the bad guy can create a bogus new ticket, get a new ticket number, and use that to log in and see all the submitted tickets for that email address.That was/is the point of sending ticket ID to the email address.

[larry_rma82]

Will you at least agree that, if a bad guy is in posession of a user's email address, they can use that email address alone to eventually read all the tickets associated with that email address?

[peter]

Well...if they can login to your email account or somehow get access to a ticket ID.

[larry_rma82]

You will be glad to know that I finally understand the problem and agree about not showing the ticket number on the "Thank You" page.

Sorry for the blockheadedness.

To others who go down the same wrong path I did - having the email address doesn't help the bad guy if they cannot read the user's email. Without access to the email account, the bad guy cannot read the new ticket number to use to log into the ticket system.

[Squadserver]

in my area most my clients know each other and dont have to guess the others emails as they all ready know it, i dont mind the inconvince of using emails to verify but so many companies auto block to many things
we use SPF correctly on our sites but clients ISP and MSN or Yahoo do not and rely on phrase filters so our Osticket emails will get held up just as a email based support form and the purpos of support is for the customer to know you are doing something and if ostickets emails are marked as spam then you dont have a happy client

I think im going to write the mod that shows the ticket and then just set their allowed tickets to 1 and autodelete closed tickets

[DJB31st]

Just incase anyone does want to implement this despite the "confidentiality" risks... All that is required is to add this into

include/client/thankyou.inc.php


<p>
As it is possible that you are unable to access your email, please see details of the ticket below
<h3 style='color:#DA0404;'>IMPORTANT! Do not loose the ticket number</h3><br/>
Ticket Number - <?=$ticket->extid;?> <br/>
Email - <?=$ticket->getEmail();?> <br/>
Login Link - <a href='http://www.example.com/support/view.php?e=<?=$ticket->getEmail();?>&t=<?=$ticket->extid;?>' target='_blank'>http://www.example.com/support/view.php?e=<?=$ticket->getEmail();?>&t=<?=$ticket->extid;?></a><br/>
</p>



Would be better if it pulled the address from the config but ran out of time to find it

[peter]

Just incase anyone does want to implement this despite the "confidentiality" risks... All that is required is to add this into


Its not a confidentiality risk issue - showing the ticket ID is a security hole/issue.

[scottro]

Yuck,

I would definitely stear away from doing this. However, for my osTickets we don't allow users to the website at all - only staff) so its not even an issue for us. Tickets are created via email ONLY. (though staff can make one in the staff panel if they wanted to).

[msuk]

My problem is my system does not send an email to the user however it does send an email to the department/staff..

why is this? therefor the only option i have at current is to display the ticket ID

[ntozier]

If you goto your admin panel, then settings tab, and scroll down until you see "Autoresponders (Global Setting)"

What do you have "New Ticket:" set to?
How about "New Ticket by Staff:"?

If you enable those it will send the email to the person regardless of whom opens the ticket (ie if a staff or if a client opens the ticket).

[msuk]

Enabled all my auto Responders are enabled...

I then took it one step further and tried to add a php() mail function on the thankyou page to mail to getEmail()

This didn't work either :/ but I know my php function mail works because I use it on other parts of my site