I am new to ajax, In my website, I am calling Ajax, it will pass parameter and it will retrieve records from database based on parameter.
But I can see the complete url link on Inspect Element's network tab like below
Employee.aspx?userid=45
I check this stack overflow link. I didn't get clear idea about it.
In some website they mention we can you Token,Authenticate the user,use cookies. But I don't understand how to use those things on my ajax code
The answer for this is not fixed it based on which approach you follow. The stack overflow link you provided pointing out the same thing about the link issue which you have right now. Any ways following are some possible approaches you can follow in order to prevent your URL visibility to end users
1. Make use of unique keys/alias/ids
In order to prevent your table's primary key to be directly revealed to the end user from the devtools you can have a user key column in your user table which have some random 4-6 digit unique code per user so to identify each of them and use these keys to communicate through URL or service calls instead of primary key itself. Same can be applied to any tables. Some people prefer username alias used in the URLs like employee name "John Marshal" can have URL like Employee.aspx?username=john-marshal
2. Token based on authentication or Cookies
This is where some learning is required. The basic idea behind it is the service which is called based on the URL will only be served to the authentic user which have the token or the cookie already present at the user's end. So in that way the call won't reveal any data it will simply return "403 Forbidden" or "401 Unauthorized" HTTP responses. And such URL will only exist on the pages which are accessible by authentic user. It means until and unless the user is logged in they can't get data from such URLs.
Still there are many ways to achieve this but these are all approaches which can be considered; you totally can't secure the requested URL its the approach which can.
Hope it helps
Related
One of my clients has a cross domain analytics set up.
Everything works well, but there are different behaviors when user gives full cookie consent and when he allows only strictly necessary cookies.
Behavior in case of full cookie consent:
GA stores data into cookies i.e. _ga cookie _ga_ID can be found in console cookie tab.
Behavior in case of only strictly necessary cookie consent:
GA stores some data in URL, for example:
https://www.example-page.com/?_gl=1*XXXXXXX*_up*MQ..*_ga*ZZZZZZZ.*_ga_YYYYYYY*YYYYYYY..
According to google documentation the second case is default behavior. And cross domain measurement is working when _gl param is added to url.
What I do not understand is why are URL params not added everytime and only when some cookies are not accepted, so I would like to get better understanding of this.
There is also a possible issue which I do not understand and that is:
GA params are added to url also when user is just switching between subsites in the same domain i.e. from www.example-page.com/home-page to www.example-page.com/about-page. If I understand correctly this should not happen as I am staying within domain.
The questions I am most interested in are:
How is GA determining if it should store its data as cookies or push it to url?
Where are these parameters stored before user redirect first time? Is it part of datalayer / google_tag_manager global variables?
Is there way to store the params somewhere else than in url when full cookie consent is not granted?
Is adding of GA params to url even when staying withing same domain a correct behavior?
Project details:
Site is running on Wordpress and use OneTrust for cookie management.
EDIT: Issue with URL resolved.
In my case this issue was caused by update of consent mode template (gtm-templates-simo-ahava). Reverting to previous version fixed the problem. Possible cause of the problem can be maybe connected to this pull request in template repository
How is GA determining if it should store its data as cookies or push it to url?
Pushing the data to url is the mechanism of cross-domain tracking. You set a list of domains that cross-domain tracking should work for. This is likely your problem here. You're not supposed to set subdomains, only TLDs in vast majority of cases.
Where are these parameters stored before user redirect first time? Is it part of datalayer / google_tag_manager global variables?
This data is stored in cookies before the user goes to a different domain. If cookies are deleted, then it's stored in the JS scope of the GA library. This implies that they would be erased and regenerated on JS context loss. Loss on a page unload, regeneration on a page load.
Is there way to store the params somewhere else than in url when full cookie consent is not granted?
Well. Yes. But very tricky and expensive. And the immediate question is why would you do that. This would defeat the purpose of blocking the cookie. Natively, GA doesn't support other methods of passing the value, but if you're into tinkering, you can either store the value on your backend and then retrieve it, using some "primary functionality" cookie. Another option is using third party server's cookies, but that would defeat the purpose even more.
Is adding of GA params to url even when staying withing same domain a correct behavior?
No, it's most likely a mistake.
Now, you really asked all the right questions, so I don't have much to add, except that disabling your primary anonymized behavioral tracking is usually a lazy "safe" choice. And lazy here implies wrong.
Normally, larger corps don't block primary tracking. They only block third party marketing-related tracking. Basically, pixels. They consider their main analytics part of the primary functionality, which is a strong case given that main analytics data is often used in debugging, performance measurement and even for app security audits.
Finally, using onetrust or a similar solution to completely manage your tracking is sub optimal. They basically just destroy all "offending" cookies all the time. This will mess up your behavioral data very significantly.
The proper way to use consent management systems is declaring user consent choice in your tag management system and then in it, block rules/tags from firing in case the consent is not given. You normally just carefully block marketing tags there based on consent. Remember, consent management systems are only deleting cookies. Because that's trivial. They don't block network requests. Absence of cookies may not prevent the data from being sent, often even uniquely identifying the client, using the primary cookie's user id, allowing to match the activity to the backend database.
i've read all the tutorials and questions asked about the subject but they contradict one another
claims(userclaims and roleclaims) are serialised into a cookie (along with custom identity user properties you specify by overriding the principle factory) but they don't get queried, they're stored in a cookie, which mean that the more claims a user have, the more data will have to round trip between the server and browser
a custom identity user property by default don't get serialised but get queried from the database, so every time you need that data it query it from the database which is more work to do on the database on each request if you frequently query for it
so which is more efficient and which is safer
for instance
IsAdmin should be a role/claim? but then if someone stole the cookie, nah nah, the cookie already contains userid/username/securitystamp, so even if it's a property, the userid on the stolen cookie would query on the custom identity user property, or is there something that will prevent this cookie from working when stolen ?
another instance
if i've 20 property for the user (first name, last name, address 1, address 2, postal code, whatever the case may be), should i simply have the user wait a bit for a bigger slower cookie to be send back and forth or should i do all the work from the db using custom identity user
but then, if i remove or add a claim to the user, would it be updated on the next request if it doesn't get queried or is the security stamp validate that this cookie is still valid ?
cause at the Task AddClaimsAsync of the userstore of efcore it only add the claim to the dbset
i apologize i know this is many questions to ask but the resources on the matter are not that good and one can easily get lost reading the identity source
Rule of thumb - put frequently added items as a claim, everything else can live in DB and be queried on demand. I.e. address 1, address 2 can't be required on every request, so keep them in the DB.
On the other hand IsAdmin (should be a role anyway) I can imagine will be checked on every request, so it should be in the cookie without having to query the db.
If you afraid of your cookies getting stolen, don't show them to anyone! set up SecurityStampValidator to do frequent checks - like every 5 minutes. This basically updates the cookie with the fresh information from your database and changes the cookie. So even if the cookie is stolen, it will only work for 5 minutes.
I don't think the two statements contradict, it depends on your configuration. The second statement mentions "by default".
You do not need to store all information in claims nor do you need all the information all the time. If you want profile information, call the server once and store the information on the client, or get it when needed only.
The same counts for authorization, in case you want to show / hide elements based on permissions. This may include a tag called "IsAdmin". Authorization should be kept close to the resource.
If your client wants to refresh the information, just call the server. Claims are not updated during each request. In general, the user has to log out and log in again. So Claims are not flexible and therefor not really suitable for properties that can change (frequently).
As for safety, it doesn't really matter that the client can alter the information, it is for display only. It doesn't change the permission in the backend.
You can consider to add something like a display name to the properties, if you are showing that in every page. You can also consider to implement caching to limit database calls. In the end it really depends on your requirements.
As for stolen cookie, you'll need to implement additional security to your server to detect suspicious behaviour. You may want to include the ip address as claim. As for the admin, add security, e.g. filter by ip address and / or use an additional code which was send by email.
For a web app I want to let users review and edit a record they made previously through a browser form. In their confirmation mail, they get an access link with a secret token, like http://myapp.com/edityourstuff/hdD8sF2m Clicking this link shows them a form in which they can edit the existing data they submitted earlier.
This is not as secure as a username/password combination, but much more convenient and suitable for my situation.
However, I want to make this as secure as possible.
GET URLs
If the link containing the secret access token is disclosed, unauthorised people can access the data. My concern here is about shared/public computers.
I was planning to tackle this problem with the following pattern:
Access to /edityourstuff/ds8sdfhe via link in email
Start a session, store the secret token in there
redirect to clean /edityourstuff without token
The app now has access to the token in the session and can display the form accordingly. And the URL bar does not show it.
My question now is: Do browsers store the initial URL, that immediately redirects to the clean URL in their history?
I know that the different HTTP redirect status codes (301, 302, 303) have different use cases in theory. Is there any information on how different browsers treat the different redirect codes in respect to (not) storing the initial URL in browser history?
I just did some quick testing myself, with Firefox 7.0.1
When using the above pattern, no matter if 301, 302 or 303 redirect, Firefox does not return to the initial URL when clicking the back button. However, it is shown in the full browsing history and is part of the URL completion list of the browser bar.
This is exactly the drawback I was hoping to avoid.
I have 2 applications, each in different domains. When a user comes to the first application, clicks a link, the user is sent to the second application.
My problem is as follows: I need to persist a sessionId from the first application to the second application. Simple enough but here's the catch. I can't use query string and I can't use cookies(since in different domains). I was thinking, is there a way to insert custom values into HTTP Headers or set some form values on an intermediate page which would then POST to the second application? So the process would be as follows:
User clicks a link on the first page, this takes the user to an "intermediate" page, this "intermediate" page sets a sessionId value in the form or http Header, then the "intermediate" page sends the user to the second application via a POST where the app will have the sessionId.
I can't use a Server.Transfer since the app is not on the same server. Help?
This is how Microfot tried to do it Does Issuing Passports Make Microsoft a Country?.
You could try and make a secure SOAP or XML request with a secure token referencing a session id you stored for the user in a shared database. You could then load the user's session based on that session id stored in the db if a match is found.
One way that you could do it is to use webservices. Before the user is to switch sites, you could give the user an unique authentication token that has been agreed upon prior to leaving.
Another thing you could do (this is not a great solution, but it works) is to use frames, and to send the child frame information through javascript (login information). I really don't like this method, because it presents so many problems that its best avoided.
What I mean:
Web services: Communicate with the other site to say "this user is currently logged in here," you can do this at login (depends how much you trust the other domain), or you can do it when the user requests to leave
Giving the user an authentication token: You can post it as a form element. Or if you had an agreement with both domains you could send it to a URL that could later be interpreted as a rediection service+authentication token confirmation portion. I.E.: domain.com/page/token+pageid-mixture
Use OpenID. It's designed for this purpose (common authentication to web sites on multiple domains). The protocol's been under development for years and has probably encountered and solved a lot of the problems you'd be likely to run into if you roll your own solution.
I have a single sign-on solution, meaning that the user will login to one site and be redirected to another. When I redirect the user I want to pass along a key that can be used to verify the user's authentication status.
Most of the examples of single sign-on I read show the login site passing the encrypted key has a query string value. I don't think this is a very good solution because it's not very REST-ful or whatever you want to call it. Instead I'd like to pass the encrypted key in the POST data. So when the user logins in, they are POSTing to another url.
Unfortunately I don't know (yet) how to do this with the Response.Redirect or Server.Transfer. I think Response.Redirect passes the same POST data along when it redirects.
Does someone know how to redirect a website user in asp.net, changing the POST data while redirecting?
(bonus question: can you change a GET to a POST while redirecting?)
Server.Transfer has the ability to maintain form data (POST values) in transition, because it is essentially transferring the same request sent by the user to a new endpoint.
Request.Redirect cannot persist POST data because a redirect is essentially sending a response back to the end-user which says "go here instead". The client then initiates a new request to that new endpoint. The client does not re-submit the POST data on the second, separate request.
However, neither POST nor GET alone are more or less RESTful - both are strings of data, just in slightly different parts of the request. Having clean, querystring-less URLs might "look REST-y", but it is cosmetic.
Here's a diagram of how the two different approaches work. As you can see, in the Redirect case, changing the POST data simply isn't possible because it's in the client's hands to form the new request to the target URL; and in the Transfer case, it makes no sense to (even if it was technically possible) because if you do need to pass additional data to the new handler, you can do so yourself:
alt text http://rexmorgan.net/rr_vs_st.jpg