Pass code from webservice through website without user detection.

[sapator]

Hi.

I am thinking on how i can pass a code through a website to a webservice without the user opening the page source and viewing the code.

Also if i encrypt the code then the user can just send the encrypted code.

So how can this be restricted for only my website to be able to pass a correct code and anyone else?

If there is nothing i can do then could i use a cookie - encrypted that will be created on the website load and decrypted on any webservice need?

I can do that with viewstate also but i prefer to leave this option out, unless is the only way.

Thanks.

[szlamany]

First is your transmission HTTPS? SSL and all...

[sapator]

Yes. HTTPS and SSL. But remember that this is supposed to be on the website client code (secretly somehow) so it can be passed through the WCF service i have build, through the usual Jquery , POST, etc.
I can encrypt it but , as I've said, someone can still send the encrypted data as is.
Not remember correctly if I can encrypt it on a cookie securely. And you and I both know how we feel about viewstate
Thanks.

P.S. Excited since I will finally do some JS after month after month of SQL (that is not that bad...Man i hate MS MVC SO MUCH!).

[szlamany]

When my users connect to my web app initially - where I authenticate the un/pw - I return a GUID that was created on the server and stored in a login tracking table in the database.

Each time the user makes an AJAX POST that GUID I also include in the transmission.

Each WEB METHOD takes that GUID from the client and goes to see if it is in an APPLICATION SPACE list(of) maintained on the server.

If it's not found the web app tells the user to login again.

If IIS recycles I write this list of GUID's to a list on disk and restore it when the application start event fires.

Since my talk to the server is always SSL I feel safe that my GUID will not be sniffed.

[sapator]

So what we can do here is have the server init a GUID every time the web app runs on a client computer and the send the p=key + guid , I am thinking, encrypted back on the server.
After the verification or in a fine amount of time the GUID is deleted so it cannot be used again.
Am I one the correct path here?
Thanks.

[szlamany]

Yes the GUID is created on the server and handed back to the client that initial time.

Since we are always SSL it's already encrypted - so we can send it clear text.

Each and every AJAX call from that point forward passes the GUID back to the server so the server can check that it's valid.

I delete my GUID's on the server (in memory array) after so much time basically to enforce an activity timeout.

[sapator]

Yep I have a 10 minutes activity.
About the SSL. If i do not encrypt the key then won't the client be able to view it? Since they key will be send from the client side.
OK he would also need the GUID to do something but still, can't he view the key?
Thanks.

[szlamany]

How do you pass the data in your POST's? I do it with JSON behind the scenes. Are you doing it in the QUERY string of the URL??

Are you also protecting against your user going rogue?

[sapator]

Haven't done anything yet (it's a future plan).
I will probably pass the data with Json and will do it with "POST" so no URL.
I am not sure about protecting the user going rogue?I don't know what do you mean.

[szlamany]

The purpose of my GUID is so that each and every request (POST) to a web method can be associated with a previously authenticated user.

Since the GUID is sent in JSON the user cannot see it.

If I was worried about users going rogue and trying to exploit and hack my web methods then I would hide the GUID in the JSON string in some way - as it could be seen with FIREFOX by the savvy user.

[sapator]

I do not really mind about the GUID. The user- rogue would have 10 minutes to try anything and at best he can order another ticket.
What i would be better of not show would be the global key that i will be using.
Image like the website is a sales channel. We have different sales channels and the specific key is for the website sales channel.
So when that key is send, we would know that it is a website sale. The problem is that they key must be send initially from the website on every sale.
So the website must either store it somewhere or it will have to ask the SQL for the key, with a "getkey" function or something that could probably send an encrypted key to the website. That won't matter since a rogue user will use the encrypted key + GUID so encrypted or not the key can be send. Also it is a unique key and cannot be changed.
So at best i can blend the GUID + key for a 10 minute transaction.I guess that is what we are concluding at?
Thanks.

[szlamany]

Do you do PAGE RELOAD's as well as AJAX calls?

[sapator]

Probably since I don't want to put everything in a single page like app but the key+guid is only needed for a specific page and situation, namely when a request for a ticket purchase is clicked.

[szlamany]

IIS gives me an APPLICATION memory space that all "sessions" will see.

You can maintain a list in memory in that APPLICATION space of the GUID and what "sales channel" they are on. And you can have the client know that sales channel value and pass it along with that security GUID. You can then check that "sales channel" against what you retained server-side so you know for sure that the window on the client side requesting something is clearly that "sales channel".

With your setup if the user clicks refresh they lose the active sale? I would imagine you just warn them of such on page unload??

[sapator]

Will think of it but i don't like the application memory space.
Yes if the user hit refresh then they loose the active sale. Goodbye goodbye my user friend! Since the sale will be initiated on one click, i really do not care if they hit refresh.It's not like an add to cart app. They will have to start allover again if they are refresh freaks.

[szlamany]

Ok - so the total knowledge of STATE - what sales channel and what user - is maintained on the page and used to submit the sale. I like maintaining state on the client side.

[sapator]

Yep.
Everything on the client.
It may ask sql for the key and GUID but it will have to be maintained on the client. Possibly a cookie if we decide to keep it like a shopping cart app.