By default, Paw will send a user agent identifying itself as Paw.
I know you can set the user agent field manually to override this and send a different value.
However, how do you not send the user agent at all? (I.e. not empty but actually not in the headers)
Related
I am currently building one web application, and I consider to use Firebase auth and its database. My concern is that if user id is on browser, does it make any security issue?
For example, say that my user id is 12345, and I would like to show some information about user 12345 on a certain page. In order to move to the certain page that I can see user's information, I click some element (like a button), and go to the page. (Ex: https://localhost:9876 => https://localhost:9876/12345) In this case, the user id is visible, but I am not sure if this is reliable approach.
Thanks.
EDIT: I just noticed that security rules should be used thanks to Eric's comment. However, I am not 100% sure if the rule can be used for auth object too. For example, auth object is used to get user id, but using user id, is it possible for someone to obtain the user's email address which is stored in auth object? For instance, in the above example, someone might obtain user 12345's email address using user id, 12345.
The correct way to secure user related resources is via a Firebase ID token. Database/Storage rules already rely on this mechanism. You cannot just rely on the correct user ID being provided. That provides no security. Instead, before return restricted resources, you should check verify the ID token and trust only its content which includes the UID. FYI: the Firebase Admin SDKs already provide an API to verify an ID token.
Typically the way to pass the ID token (if you are not using real-time database), is as follows:
Single page app: you can call getIdToken() and then pass the latest ID token in the URL query parameter, post body or the header as you send an XHR request to your server.
Traditional website: you have to set a session cookie. The easiest way is to set the ID token as session cookie and keep updating it on expiration. On your backend, you will verify this before returning the user specific resource.
My website sends usual Page views and events to GA using JavaScript API.
Days after user session, I need to send more data from server using Measurement Protocol.
After sending the nonInteractive hit with updated custom dimensions, I see that user's device category changed from the original device category (Desktop/Mobile/Tablet) to Desktop device category.
I understand that GA recognize server's User-Agent as Desktop device.
Is any way to make GA ignore server's User-Agent?
You can override the user agent by collecting the users user agent at the time which you are collecting their client id, and sending this user agent along with the measurement protocol hit with the key ua=.
For example:
v=1 // Version.
&tid=UA-XXXXX-Y // Tracking ID / Property ID.
&cid=555 // Anonymous Client ID.
&t=pageview // Pageview hit type.
&uip=1.2.3.4 // IP address override.
&ua=Opera/9.80 // User agent override.
For an overview see:
https://developers.google.com/analytics/devguides/collection/protocol/v1/parameters#ua
For specific reference see:
https://developers.google.com/analytics/devguides/collection/protocol/v1/parameters#ua
I wonder how does ASP.NET check if an anti-forgery token is valid or not? Like where is ASP.NET storing those tokens? And how are they stored?
The short version is that a generated token is stored in 2 places: (a) cookie (b) hidden form value. When the form is submitted, these 2 values are compared against each other to determine if they are valid. For further reading:
http://www.asp.net/web-api/overview/security/preventing-cross-site-request-forgery-(csrf)-attacks
http://www.codeproject.com/Articles/793384/ASP-NET-Anti-Forgery-Tokens-internals
A stepwise explanation that is more clear than the accepted answer imho (from https://learn.microsoft.com/en-us/aspnet/web-api/overview/security/preventing-cross-site-request-forgery-csrf-attacks)
The client requests an HTML page that contains a form.
The server includes two tokens in the response. One token is sent as a cookie. The other is placed in a hidden form field. The tokens are generated randomly so that an adversary cannot guess the values.
When the client submits the form, it must send both tokens back to the server. The client sends the cookie token as a cookie, and it sends the form token inside the form data. (A browser client automatically does this when the user submits the form.)
If a request does not include both tokens, the server disallows the request.
The above description is not all what is done, in case of AjaxRequest the antiforgery, specifically in get requests, will not usually send the Form with the hidden value for comparison, instead you will need to set a header value with the same content of the cookie via javascript.. the header name that you should set is by default X-XRF-Token header [related to angularjs] ... of course you will need to disable CORS or enable it for only specific domains to protect the APIs, SAMEORIGIN also need to be set to avoid clickjacking ..
I have a web application that creates user accounts, but I would also like to have the ability to have users that can sign up for subscriptions without accounts. All they have is a subscription page to modify email settings and enable the newsletter subscription.
My questions is how do I verify that the user is who they say they are without a username/password, and my second is how should they access this page. I dont want just anyone typing in the url with the email and access subscription settings for that user.
For each user entry you create a unique access code that you use in the url in order to validate that this is the user you want.
The subscription form will give these options:
subscribe by filling in your email
request to change your settings by just putting your email to another field
both action will send an email to you with a special url
the first to validate that this is made by you so you will enable this user & his email
the second to send him another special url to make any changes to his settings in the case that this use is active in your database.
For this unique code you can use md5 of his email with a timestamp when he was registered.
I have a simple web application set up where admins can create users. Users do not create themselves. All an admin has to do is enter a username and an e-mail and a temporary password is sent to the user for them to login. This e-mail is sent in plain text format. If the user is logging on for the first time, they are required to change their password and enter a security question and answer. The user obviously has to know their temporary password in order to login for the first time and this is the only way I know of letting them know (through e-mail). The other option would be to have the admin call the user and tell them over the phone or in person their temporary password, but this is not practical. How could I handle a situation like this?
I typically use a temporary url based on an invite record on the back end. Essentially you create an invite record and generate a hash based on some information perhaps the users email address, a timestamp and a random value. Store the hash as part of the invite record and then send them a url with the hash as the parameter.
When they click the link lookup the invite and validate that it exists and has not been used - then allow them to setup their password and invalidate the invite.
It gets rid of the need to send any sort of password and you can set an expiry on your invite records if you want as well.
The scenario you describe is very common- emailing a temporary password and requiring it to be changed on first login. Unless you have a specific problem with this model I see no reason not to use it. Having an admin call users can get complicated- I would avoid this at all costs.
You can generate a custom url with a password and user hash as argument where the user has to log itself. The hash will be difficult to retrieve if the attacker does not have the information