SUFC Online Ticket system security

All advertisments are hidden for logged in members, why not log in/register?

Highbury_Blade

Bummed in the gob
Joined
Aug 9, 2009
Messages
24,619
Reaction score
13,220
I posted about the security of (or lack of security) on SUFC online ticket system on another thread, but's worth highlighing in it's own thread.

I was trying to replicate a problem that Mousey was having, but i couldn't remember my password. So i followed the instructions to get a new one, expecting that i would get an email with instructions on how to reset my password.


What i actually got was this

Screen Shot 2014-12-30 at 13.56.54.png

They've sent me my actual password, in an email.


What this means, is that your password is stored in a database, unencrypted, and then transmitted in plain over email, which is not a secure medium.

There are a couple of things wrong with this

Firstly your email could get intercepted. They would then have access to your account which means they would have your home address & date of birth. They'd also have access to any details of your friends or family that you have linked to your account. They could then see what your purchase history was. Perhaps you've bought a few tickets for an upcoming away game? Somebody then has your home address, and the knowledge that you're not going to be there on a certain date.

This possible all sounds a bit fanciful, and the likelihood is that that would never happen.

What's for more worrying is that if they're getting password management wrong and storing details unencrypted in a database, what else are they getting wrong? This is a site that takes credit card details. Maybe they're storing them unencrypted too? How vulnerable is the site to all sorts of potential attacks. Password management is the most basic form of ssecurityon a site. If that's been done incorrectly i have very little confidence that they'd be getting much else right.
 

Not disagreeing with any of that other than the credit card bit. It is done third party and uses secure pay. Not sure if the rest of the site uses https or not though. Certainly not there at log in.
 
Not disagreeing with any of that other than the credit card bit. It is done third party and uses secure pay. Not sure if the rest of the site uses https or not though. Certainly not there at log in.


The whole lot is done by a third party. It isn't run by SUFC.
 
It happens all over the place, in different browsers and on different Windows platforms.

Error below:

Server Error in '/' Application.
Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that <machineKey> configuration specifies the same validationKey and validation algorithm. AutoGenerate cannot be used in a cluster.

http://go.microsoft.com/fwlink/?LinkID=314055

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.Web.HttpException: Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that <machineKey> configuration specifies the same validationKey and validation algorithm. AutoGenerate cannot be used in a cluster.

http://go.microsoft.com/fwlink/?LinkID=314055

Source Error:

The source code that generated this unhandled exception can only be shown when compiled in debug mode. To enable this, please follow one of the below steps, then request the URL:

1. Add a "Debug=true" directive at the top of the file that generated the error. Example:

<%@ Page Language="C#" Debug="true" %>

or:

2) Add the following section to the configuration file of your application:

<configuration>
<system.web>
<compilation debug="true"/>
</system.web>
</configuration>

Note that this second technique will cause all files within a given application to be compiled in debug mode. The first technique will cause only that particular file to be compiled in debug mode.

Important: Running applications in debug mode does incur a memory/performance overhead. You should make sure that an application has debugging disabled before deploying into production scenario.

Stack Trace:

[ViewStateException: Invalid viewstate.
Client IP: #################
Port: ###########
Referer: http://www.sufc.talent-sport.co.uk/PagesPublic/Login/LoggedOut.aspx
Path: /PagesPublic/Login/LoggedOut.aspx
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; Touch; rv:11.0) like Gecko
ViewState: /wEPDwUJLTUyMzk3ODU1D2QWAmYPZBYCAgMPZBYCZg8WAh4FY2xhc3MFDmZvcm0tbG9nZ2Vkb3V0FhACAQ9kFgpmD2QWAgIBD2QWBGYPDxYGHglMb2dpblRleHQFBUxvZ2luHgpMb2dvdXRUZXh0BQZMb2dvdXQeB1Zpc2libGVoZGQCAQ8PFgIeBFRleHQFDlN3aXRjaCBBY2NvdW50ZGQCAg9kFgICAQ8PFgIeCEltYWdlVXJsBSAvQXBwX1RoZW1lcy9TVUZDL0ltYWdlcy9sb2dvLnBuZ2RkAgYPDxYCHwNoZBYIAgEPDxYCHwNoZBYCAgIQPCsACQEADxYCHg1OZXZlckV4cGFuZGVkZ2QFDGN0bDAwJGN0bDA1fGQCAw8PFgIfA2hkZAIFDw8WAh8DaGQWAmYPFgIfA2hkAgcPDxYCHwNoZBYCAgIQPCsACQEADxYCHwZnZAUMY3RsMDAkY3RsMDd8ZAIID2QWAgIBD2QWBgIBDw8WAh8EBQxRdWljayBTZWFyY2hkZAIHDw8WAh8EBQJHb2RkAgkPDxYEHwQFD0FkdmFuY2VkIFNlYXJjaB8DaGRkAgoPZBYCZg8WAh8EBaAWPCEtLSBkcm9wIGRvd24gbWVudSAtLT4NCg0KPGRpdiBjbGFzcz0ibmF2IHByaW1hcnkiPg0KICA8dWw+DQogICAgPGxpPjxhIGhyZWY9Ii9QYWdlc1B1YmxpYy9Ib21lL2hvbWUuYXNweCIgY2x...]
[HttpException (0x80004005): Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that <machineKey> configuration specifies the same validationKey and validation algorithm. AutoGenerate cannot be used in a cluster.
http://go.microsoft.com/fwlink/?LinkID=314055]
System.Web.UI.ViewStateException.ThrowError(Exception inner, String persistedState, String errorPageMessage, Boolean macValidationError) +156
System.Web.UI.ObjectStateFormatter.Deserialize(String inputString, Purpose purpose) +432
System.Web.UI.ObjectStateFormatter.System.Web.UI.IStateFormatter2.Deserialize(String serializedState, Purpose purpose) +8
System.Web.UI.Util.DeserializeWithAssert(IStateFormatter2 formatter, String serializedState, Purpose purpose) +40
System.Web.UI.HiddenFieldPageStatePersister.Load() +248
System.Web.UI.Page.LoadPageStateFromPersistenceMedium() +238
System.Web.UI.Page.LoadAllState() +36
System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +6704
System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +245
System.Web.UI.Page.ProcessRequest() +72
System.Web.UI.Page.ProcessRequestWithNoAssert(HttpContext context) +21
System.Web.UI.Page.ProcessRequest(HttpContext context) +58
ASP.pagespublic_login_loggedout_aspx.ProcessRequest(HttpContext context) +37
System.Web.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +341
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +69

Version Information: Microsoft .NET Framework Version:4.0.30319; ASP.NET Version:4.0.30319.18446
 
Also, the fact that i can generate this page is interesting.

This is the default error page for applications built using Microsofts .NET platform, and you should not be able to see this page on a production website. The fact that i can produce this can tell a potential attacker a couple of things.

a) That the website is using .NET and exactly what version, so a potential attacker could probe the ticket site using known vulnerabilities on that platform

and b) this page could tell me all sorts of lovely stuff about the internal workings of the site if i tested it with various URLS and specially designed HTTP Form posts.

Screen Shot 2014-12-30 at 15.13.11.png
 
It happens all over the place, in different browsers and on different Windows platforms.

Error below:


Looks like they've added some more servers to cope with demand but not configured them right. It's not a browser or operating system issue.
 
I posted about the security of (or lack of security) on SUFC online ticket system on another thread, but's worth highlighing in it's own thread.

I was trying to replicate a problem that Mousey was having, but i couldn't remember my password. So i followed the instructions to get a new one, expecting that i would get an email with instructions on how to reset my password.


What i actually got was this

View attachment 10084

They've sent me my actual password, in an email.


What this means, is that your password is stored in a database, unencrypted, and then transmitted in plain over email, which is not a secure medium.

There are a couple of things wrong with this

Firstly your email could get intercepted. They would then have access to your account which means they would have your home address & date of birth. They'd also have access to any details of your friends or family that you have linked to your account. They could then see what your purchase history was. Perhaps you've bought a few tickets for an upcoming away game? Somebody then has your home address, and the knowledge that you're not going to be there on a certain date.

This possible all sounds a bit fanciful, and the likelihood is that that would never happen.

What's for more worrying is that if they're getting password management wrong and storing details unencrypted in a database, what else are they getting wrong? This is a site that takes credit card details. Maybe they're storing them unencrypted too? How vulnerable is the site to all sorts of potential attacks. Password management is the most basic form of ssecurityon a site. If that's been done incorrectly i have very little confidence that they'd be getting much else right.
My big worry is they could buy my tickets and I'd miss the match :mad:

Jesting apart HB you do well to point this out. Are you taking it up with the club? Personally I enter my credit card details each time and don't let them store the details.
 
My big worry is they could buy my tickets and I'd miss the match :mad:

Jesting apart HB you do well to point this out. Are you taking it up with the club? Personally I enter my credit card details each time and don't let them store the details.


The point is you don't know if they store your details or not.
 
What a bag of spanners. If the club don't take this up with their supplier they need a shoeing.
 
Not disagreeing with any of that other than the credit card bit. It is done third party and uses secure pay. Not sure if the rest of the site uses https or not though. Certainly not there at log in.


In addition i assume by securepay you mean the visa/Masterdcard stuff 3d secure stuff? All that does is provide an extra layer of authentication. Your card details are definitely handled by the sufc ticket site.
 
I have managed to enter all 4 customer numbers with the correct combination of ticket categories and managed to update my basket!

However, clicking 'Checkout' loads the same screen up and then tells me my basket is empty.

Wankbiscuits.
 
  • Like
Reactions: Dkc
I tweeted the club, but they just told me to email the ticket office. I'm not sure i can be arsed to get into a long drawn out debate over email with some people who probably don't know the first thing about web security (That isn't a dig at the box office though - most people don't). Suffice to say it's probably not going to be a quick problem to solve given that the club aren't in charge of it. If someone from the club (Rooks perhaps) wants to get in touch then i'll happily talk it through with them.

They could fix the issue with sending the passwords in plain text fairly quickly i would guess, by implementing a password reset system. but that still wouldn't solve the problem that the passwords (and who knows what else) are stored unencrypted.

All i know is i won't be using the online system anymore, and i wouldn't recommend anyone else does either. The shitter is that since you need to give your address to buy a ticket, even if you do all your purchases offline, that information is stored in the same system, along with your purchase history.
 
I've raised a few issues regarding the online ticketing previously, will do so again tonight.
 
I've raised a few issues regarding the online ticketing previously, will do so again tonight.


Nice one. I'd stress that the only reason i've posted it on here is to make the problem visible, and therefore a more urgent issue for the club to deal with.
 

Nice one. I'd stress that the only reason i've posted it on here is to make the problem visible, and therefore a more urgent issue for the club to deal with.

Yeah, one of your issues is similar to a previous report of mine too :)

With Mousey 's case, it might be as simple as them setting the key correctly (someone forgot on a server in the cluster?).
 
Yeah, one of your issues is similar to a previous report of mine too :)

With Mousey 's case, it might be as simple as them setting the key correctly (someone forgot on a server in the cluster?).


It probably is. Just looking at the site's html makes my head hurt. Microsoft Webforms was an utter clusterfuck.

 
The day it goes full circle and we can use quill pen again will be great.

Bloody computers won't catch on............

UTB
 
Don't forget they will also share your details with other clubs like Chesterfield without asking you first
 
I posted about the security of (or lack of security) on SUFC online ticket system on another thread, but's worth highlighing in it's own thread.

I was trying to replicate a problem that Mousey was having, but i couldn't remember my password. So i followed the instructions to get a new one, expecting that i would get an email with instructions on how to reset my password.


What i actually got was this

View attachment 10084

They've sent me my actual password, in an email.


What this means, is that your password is stored in a database, unencrypted, and then transmitted in plain over email, which is not a secure medium.

There are a couple of things wrong with this

Firstly your email could get intercepted. They would then have access to your account which means they would have your home address & date of birth. They'd also have access to any details of your friends or family that you have linked to your account. They could then see what your purchase history was. Perhaps you've bought a few tickets for an upcoming away game? Somebody then has your home address, and the knowledge that you're not going to be there on a certain date.

This possible all sounds a bit fanciful, and the likelihood is that that would never happen.

What's for more worrying is that if they're getting password management wrong and storing details unencrypted in a database, what else are they getting wrong? This is a site that takes credit card details. Maybe they're storing them unencrypted too? How vulnerable is the site to all sorts of potential attacks. Password management is the most basic form of ssecurityon a site. If that's been done incorrectly i have very little confidence that they'd be getting much else right.
Storing unencrypted passwords is such a big no no. The idea that a business of this size still does this is shocking. There is a site for naming and shaming these people -http://plaintextoffenders.com. Maybe you should add it to this site and inform the club that you have done so, you'd hope it would help them understand the seriousness of the issue.
 
By the way, if anyone uses a password on this site for other sites, especially your email, change it immediately.
 
Because if you use the same password for a website that has your email address also for your email account then any compromise of your password will allow those that did it to access your email via a web interface. From this they can reset passwords for other sites etc. by asking for a password reset. Always use unique passwords for every site if possible. A basic one is to say have a secure phrase that has the first and last letter of the site swapped as a prefix, so for instance a password for Amazon would be naSwfiua, with Swfiua being your common phrase. Not great, but better than using the same password with the same email address or username on multiple web sites.
Never save card details on web sites if possible, it's not worth it for the amount of time saved entering them each time, including deleting them from your xbox, otherwise unless settings deliberately changed others, such as your kids, can purchase in-game purchases.
 
Because if you use the same password for a website that has your email address also for your email account then any compromise of your password will allow those that did it to access your email via a web interface. From this they can reset passwords for other sites etc. by asking for a password reset. Always use unique passwords for every site if possible. A basic one is to say have a secure phrase that has the first and last letter of the site swapped as a prefix, so for instance a password for Amazon would be naSwfiua, with Swfiua being your common phrase. Not great, but better than using the same password with the same email address or username on multiple web sites.
Never save card details on web sites if possible, it's not worth it for the amount of time saved entering them each time, including deleting them from your xbox, otherwise unless settings deliberately changed others, such as your kids, can purchase in-game purchases.
I know all that but the post was made that we should change our password as if the issue with the United ticketing site had somehow affected this site, I just couldn't understand how this could be the case.
 
I know all that but the post was made that we should change our password as if the issue with the United ticketing site had somehow affected this site, I just couldn't understand how this could be the case.
Because a potential issue with a site we all use that stores usernames, passwords and other information has been highlighted, and highlighted on a public forum so making it more of a target than it was before. It is basic security to not re-use usercodes and passwords, especially for email. I know of accounts compromised at my employment because the users used their work email address and password to access web sites that were then comprimised. Very bad idea for them.
 
Because a potential issue with a site we all use that stores usernames, passwords and other information has been highlighted, and highlighted on a public forum so making it more of a target than it was before. It is basic security to not re-use usercodes and passwords, especially for email. I know of accounts compromised at my employment because the users used their work email address and password to access web sites that were then comprimised. Very bad idea for them.
Having different passwords for every site you use just isn't possible, you just wouldn't be able to remember them all. Including the ones I need for work, there must be 40-50 different sites, maybe more, that I need a password for. I've probably got about 10 different passwords that I use
 
Last edited:

All advertisments are hidden for logged in members, why not log in/register?

All advertisments are hidden for logged in members, why not log in/register?

Back
Top Bottom