I have a web application that has form based authentication.
the application has registration functionality also. Since last few weeks, i have observed that some users with specific domain is making fake entries into the website and getting the benefits as We do not have any approval workflow.
this user either do it manually or run some script. We thought that we can restrict the registration process as per IP based, however this is not possible to get the visitor exact IP address using C# (please correct if i am wrong).
Can we do it using some other techniques. our requirement is - single registration from a machine per 2 days.
unfortunately I would call this mission impossible.
Idea 1: IP address. The user can use a proxy to register multiple accounts depending on how many proxy he can find (there are a bunch on the internet for free)
OR they could just fake the ip package by putting a random ip in the header. Since all they need is to register so it doesn't matter if the confirmation message was sent to another random guy
Idea 2: one registration per machine. I could fake as many machines as I want with virtual machine and you will have no way to tell from http request.
Alternatively I could just fake all the information with raw http request and I can do that with a script with no issue.
And from what I know you don't have the system right to read hardware id from js (correct me if im wrong)
No method is guarantee to restrict 2 registration per day but IP based method should work against most normal users. Do keep in mind that everyone using the same router could have the same IP (example school, public wifi in apartment)
You could find out the user's IP address within HttpContext object
Whatever your restriction would be - it will be based on the data the browser sends (as long you restrict a specific computer).
Your main desire is to create a "footprint" on that machine in order to use it later - per request.
Whatever your manipulation would be, you should also obfuscate your JS code.
for example, on pageload code you can request for httpheaders dedicated to that machine and save them in cache, then you generate a guid for the client which it suppose to use in order to register.
another option is to use AES to encrypt the data before sending it "on the wire", that way you won't be able to manipulate it.
the most important thing is that once you "drop" a js code on the client he can do whatever he wants, the question is how hard it would be.
**edit:
a more secured way but more complicated that i have once used is creating a sync-key.
an async ajax call to the server requesting an encryption key.
the server call will save the new guid-key in memory and will generate a new one for each request.
you can use this idea to keep track of user debug and browser behavior.
as debuging will hold the code from running the sync key will be change and you can "catch" him.
Neither cookies nor IP can protect against fake entries.
You should look at it from another side. You get unwanted entries and you don't know if it's an automated bot, or spammer, or someone who just doesn't care about your data. Instead of banning entries you should think how to validate them. For example, if you get "aaaaa" as a name and "bbbbb" as an email address - add, at least, regexp validation on client and server side to ensure you get data in a required format. Next level would be to verify the email address by querying the mail server or sending validation email. This will not only help to stop spammers, but also people who doesn't care. If you think it's an automated bot - add a captcha. In case of emergency - ban IP in the web.config (See ASP.Net How to limit access to a particular IP address to a particular page through web.config file (.htaccess similar)?)
Related
I got questions about security. lets say I have data in a div like so
<div id="Q9vX" class="mainContent" data-compname="comp1" data-user="57f70c8e78ae49d41c78876a" data-shortid="Hy85nKVR">
and I do a post request that sends the compname and user id .Couldn't someone change the data-user attribute value before it was sent? Since I'm doing DB operations based on the ID in the div can someone change the id and have the operation occur for the id the villain entered and not the one I initially intended. . I use mongodb, heroku, express. I'm afraid of sessions because they expire and I'm not too comfortable with them. What is the standard procedure for something like this?
For example this div is for a review placed by a user that has the id 57f70c8e78ae49d41c78876a. So if everything went normal and the user presses submit the review will be assigned to that users's Id. but lets say someone decides to go into firebug and changes the id would the review be registered to this new ID?
The value could be changed a user through the developer tools or through a cross site scripting attack where malicious code is injected onto the page. This could be done a number of ways such as adding the code to a file on your server, adding the code to your database if it uses a CMS, or through another means such as a browser extension.
If you have no server side access controls, someone could write a script that compromises the availability or integrity of your data. The availability could be compromised through a denial of service attack where thousands of fake requests are sent to the server trying to exceed the number of concurrent database connections preventing a legitimate user from connecting. The data integrity could be compromised by sending lots of fake requests to the database which could be difficult and time consuming to identify and remove. Also if the review is like a comment box where users can enter data that's displayed on the site, it could be used to inject malicious cross site scripting code.
If you are concerned about security I recommend that you implement access control such as sessions, sanitize the data coming in and going out of your database, and use a secure HTTP connection on your web server.
The Express JS website have an article about security best practices.
I am trying to send transaction data to UA from a webshop which is only creating orders once it has received a "push" from a payment processing API. A success page is displayed to the customer independently from the order being created, meaning the tracking script (UA via GTM with data layer) does not have access to the order data.
This gives me the headache of trying to track transactions made through the webshop server side, instead of client side. Yet I still want to tie the transaction to the unique visitor ID who made the purchase, not just a random Client ID each time.
My site is using analyics.js (UA profile). Therefore I thought somewhere a client ID would be stored as a cookie, and I do see a _ga cookie there which I believe is the client ID, which looks like this:
GA1.2.1586737968.1429871710
The documentation for getting cookie and user identification states the following:
You should not directly access the cookie analytics.js sets, as the cookie format might change in the future. Instead, developers should use the readyCallback to wait until analytics.js is loaded, and then get the clientId value stored on the tracker.
... which is not helpful to me, as I have to do this server side. But anyway, this client ID does not even fit the description of what a client ID looks like, although it does appear to match a legacy format. Sort of.
Couple of questions then:
Is it just those last two numbers 1586737968.1429871710 that I need to be parsing from the _ga cookie and sending as a client ID? Or is the whole thing ok?
Are there any scripts/libraries that will do this for me so I don't have have to worry about Google suddenly giving new visitors the client ID based on the new UUID v4 format?
Does this approach have any obvious flaws?
Answers:
Yes the cid value should just be the last 2 numbers as you rightly point out. (this is experience from client setups that already successfully use Measurement Protocol on an ongoing basis)
Nope, not as far as I am aware, best to do it yourself. It will only be a few lines of code to detect what format you're seeing in the cookie and what, therefore you need to send through.
not really. It is a common enough scenario.
I need a primer web/javascript security.
According to How to use an HTML/JavaScript client for Windows Azure Mobile Services, in javascript on the client side, after including a link to MobileServices.Web-1.0.0.min.js you're supposed to create a client like this:
var MobileServiceClient = WindowsAzure.MobileServiceClient;
var client = new MobileServiceClient('AppUrl', 'AppKey');
which means including my AppKey in the javascript on the page. Should I be worried about the AppKey being public?
Also, it seems easy enough for someone to put an XHR breakpoint in to read the X-ZUMO-APPLICATION and X-ZUMO-AUTH headers while making a REST call when logged in. The usefulness of this is somewhat reduced with a cross-origin resource sharing whitelist, but what's to stop someone with this information from adding javascript to the page and executing arbitrary operations on my backend database? Restricting table permissions to authenticated users wouldn't help in this scenario.
Do I need to be concerned? What do banking apps do about this sort of thing?
In the same link which you shared, application key is defined as a not safe mechanism to authenticate users - A unique value that is generated by Mobile Services, distributed with your app, and presented in client-generated requests. While useful for limiting access to your mobile service from random clients, this key is not secure and should not be used to authenticate users of your app.
More over when you enable some authentication on all the endpoints either using ACS or through Open Authentication, if you main ASP.Net/PHP etc page got authorized, then browser is going to handle federation of identity through cookies for next on-going calls till your session ends.
In most of the applications having HTTPS would protect from Man in middle attacks. Also strong encryption logic on cookies along with very specific expiry times would increase the bar of security. Also IP address based checks would definitely help in improving security.
ramiramilu's answer covers most of the question. There's one more thing which I'll add:
Also, it seems easy enough for someone to put an XHR breakpoint in to read the X-ZUMO-APPLICATION and X-ZUMO-AUTH headers while making a REST call when logged in
Yes, someone can add a breakpoint and find out the value of the X-ZUMO-AUTH header which they're sending. But the value of that header is specific for the logged in user (in this case it would be the "attacker" [him/her]self) - it wouldn't be able to get information from other people out of that header. And there are even easier ways to get the value of that header (just browse to https://<mobileservicename>.azure-mobile.net/login/<authProvider> and after entering your credentials you'll see the header encoded in the URI).
I need to somehow detect the IP address of some of my website visitors and let them access the website without loggin in. Currently the content of the website is password protected and the visitors should log in in order to get access to the content. But I was wondering if there is a way to let some of our customers to get access without logging in by detecting their IP address.
Is this possible? If yes, what's the best solution?
Thanks
First off; this shouldn't be a Javascript question. You can't write site security in Javascript, because it runs on the client's computer, and you can't trust that computer. They could just open devtools and replace "if (loginOk())" with "if (true)"
Usually, this is accomplished not via IP address (which is pretty easily spoofed) but with some sort of randomized cryptographic hash given to them as a cookie. I can summarize it for you in a short way, but you'll want to look up the idea of "oauth tokens".
User logs in using their username and password
In the Response to their login action, the server sets cookie 'mysite_login_token' to a highly randomized string based off of their user information and the current date, ie 'noonewilleverguessthisstringofletters' (well, no, not that exactly - like I said, read more specialized articles on the subject).
In all subsequent requests to sensitive information, the server checks the sent value of 'mysite_login_token', and makes sure it matches the stored value for that username.
If the user logs off, then the server deletes its copy of that token so it can't be used again.
you can't in pure javascript; you can use a server side service using .net or php and use XHR to fetch the result
The IP address could be useful for making an initial guess at who might be on your system if no login or cookie is presented. The IP can be used to obtain their approximate location or for logging the activity of anonymous users. The cookie is certainly a better way to re-identify a client machine than an IP, because dynamic IP's change periodically. Still identifying a machine is not the same as identifying a particular user. The IP or cookie for a machine at a public library won't identify a particular user. See: geolocation website
I am building a WebApp which connects to my server through a web service.
Users (there is no login) which use the webapp can send their scores to the
server.
The code is written mostly in javscript, so anyone can read it.
As I know there is no 100% gurantee method of doing this, I am just looking for ideas
how to make it as hard as possible for users to send false scores.
Ideas?
10X!
EDIT
The server side web service is an asmx (.net) web service hosted on an IIS.
I can modify it as needed.
I'd say the best thing to do would be to have a webservice call that generates a guid on the the serverside, which is passed back. This becomes your session token. It's stored on the database or in cache on the server
Each subsequent call requires the passing of the token back to the server, which validates the token. If they pass a bad token you don't update.
This will only insure that the calls come from the correct process. They won't be able to spoof the entry with a single call
For a process (you seem to be talking about a game?) with a limited number of interaction points, you can record each user interaction and play it back to check that it results in a certain score at the server side (either in real time or later on for suspicious scores).
Otherwise (and this is typically impractical for an real-time action game where there are too many interaction points), there is not much you can do. You can have the game digitally sign the information it is submitting... but given that you are giving the full code including signing key to the client side, it is still easy for an attacker to obtain the key and sign invalid scores.
At this point you get yourself into an obfuscation arms race - how much can you make the client-side code unreadable and difficult to unravel, to prevent attackers from obtaining the key? You can never win this game, only deter the casual attacker. And ultimately you have to protect the entire client-side process from alteration, to stop all other forms of cheating (eg using Firebug to change variables like score or lives).