Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
Lets say I am making a web app (e.g. mean stack) for an exhibition, i want to ensure my server only take requests from users who are really in the venue, how can I do it? What are the common attacks?
The short and generic answer is you cannot really do this, but read on.
The question you need to answer is against what do you want to protect your app, what is the threat that you are trying to mitigate.
You can build any protection in your mobile app (like for example the one in the other answer), but keep in mind that the client is fully controlled by the user. For example the user may fake location coordinates for the app (see Pokemon Go), it is very easy to do either in an emulator or an actual device. Or even easier, the user can just make requests from an arbitrary source, not your application. A server request would have to contain the location of the user - but the user can send whatever he wants. So in short, anything on the client is fully controlled by the user.
So this leads to server-side protection as the only way for an actually secure solution (one that is reasonably hard to circumvent). The only source where your server knows where physically the client is if the client tells the server - but we have seen above that is unreliable.
However, there is one thing a client can't reasonably fake (at least not easily), and that is the client IP address. So pretty much the only thing you can do to prevent users not being present at a venue from using your service is to lock it down on the network level, for example your API server should only be accessible from the IP range that the wifi at the venue provides (presumably a local address range, or if your API is in the cloud then the public IP address or range of the venue).
Save your venue location in your app or on your server side. Then try keep track of users by getting their location around 100 ms or a Radius which you choose.
add CoreLocation.framework to BuildPhases -> Link Binary With Libraries (no longer necessary as of XCode 7.2.1)
import CoreLocation to your class - probably ViewController.swift
add CLLocationManagerDelegate to your class declaration
Add NSLocationWhenInUseUsageDescription and NSLocationAlwaysUsageDescription to plist
init location manager:
locationManager = CLLocationManager()
locationManager.delegate = self;
locationManager.desiredAccuracy = kCLLocationAccuracyBest
locationManager.requestAlwaysAuthorization()
locationManager.startUpdatingLocation()
get User Location By:
func locationManager(manager: CLLocationManager, didUpdateLocations locations: [CLLocation]) {
var locValue:CLLocationCoordinate2D = manager.location.coordinate
print("locations = \(locValue.latitude) \(locValue.longitude)")
}
Do have a look into thisTracking Location
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 11 months ago.
Improve this question
I've been searching how to make a public http request secure and all the answers are to use a token like JWT.
But from what I understand, the reason for using this token. Isn't this to prevent someone from trying to modify someone else's data other than your own?
Then user can still manipulate his own data using his own tokens. Because when you first connect to the app, you will get a token from the server.
That person can modify his or her data at any time. Wouldn't he be able to modify the game points he has at any time? (I actually saw an answer in another answer (which said to make that http call only available once after the game is over))
but if he knows the jwt token and http request url then he still can modify right??
Are JWT tokens used in the worst case to keep someone else's data from being touched?
The JWT token is just used identify the user making API request and checking whether the user is authorized to make that request. When you decode a JWT (Firebase Auth's JWT for this example), you can read user's UID and custom claims, etc.
Passing user ID directly in API requests is not a good idea because they are usually public (e.g. your Stackoverflow ID is 18516895) and easy to guess. So I can just try passing some random numbers/string and might be able to make requests on behalf of someone else. So JWTs are mostly used for Authorization and Information Exchange.
Also checkout: Introduction to JSON Web Tokens
But suddenly I want to raise my stack overflow score. Then just checking the token is not enough for server I guess. right? How do you prevent in this case?
Allowing users to update their score doesn't seem to be a good idea. Instead the score should be done totally on back-end and can be triggered by any action such as user winning the game.
Take Stackoverflow for example, only the person who has asked the question can mark any of the answers as accepted. This is authorization. No one else is allowed to do so. After an answer is accepted, the system updated answerer's score (reputation), so there is no API request that is made from client side to increase score.
The flow could be like:
Questioner accepts an answer
Verify JWT, marked as accepted if owner of question
Increase score (reputation) of answerer
Adding to another case of single player game Tetris where the user directly needs to update server for a win and earn points as discussed in comments, it might be best to send every move to server and run all game win logic on backend instead of checking for win on client and letting users hit a /win API over and over again. If the game is completed, then credit points to user if won.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 11 months ago.
Improve this question
I've been searching how to make a public http request secure and all the answers are to use a token like JWT.
But from what I understand, the reason for using this token. Isn't this to prevent someone from trying to modify someone else's data other than your own?
Then user can still manipulate his own data using his own tokens. Because when you first connect to the app, you will get a token from the server.
That person can modify his or her data at any time. Wouldn't he be able to modify the game points he has at any time? (I actually saw an answer in another answer (which said to make that http call only available once after the game is over))
but if he knows the jwt token and http request url then he still can modify right??
Are JWT tokens used in the worst case to keep someone else's data from being touched?
The JWT token is just used identify the user making API request and checking whether the user is authorized to make that request. When you decode a JWT (Firebase Auth's JWT for this example), you can read user's UID and custom claims, etc.
Passing user ID directly in API requests is not a good idea because they are usually public (e.g. your Stackoverflow ID is 18516895) and easy to guess. So I can just try passing some random numbers/string and might be able to make requests on behalf of someone else. So JWTs are mostly used for Authorization and Information Exchange.
Also checkout: Introduction to JSON Web Tokens
But suddenly I want to raise my stack overflow score. Then just checking the token is not enough for server I guess. right? How do you prevent in this case?
Allowing users to update their score doesn't seem to be a good idea. Instead the score should be done totally on back-end and can be triggered by any action such as user winning the game.
Take Stackoverflow for example, only the person who has asked the question can mark any of the answers as accepted. This is authorization. No one else is allowed to do so. After an answer is accepted, the system updated answerer's score (reputation), so there is no API request that is made from client side to increase score.
The flow could be like:
Questioner accepts an answer
Verify JWT, marked as accepted if owner of question
Increase score (reputation) of answerer
Adding to another case of single player game Tetris where the user directly needs to update server for a win and earn points as discussed in comments, it might be best to send every move to server and run all game win logic on backend instead of checking for win on client and letting users hit a /win API over and over again. If the game is completed, then credit points to user if won.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I've notoced lots of websites allow users to register by simply asking their email and password [aside all the other information like name, username, genre etc.]. And the users don't have to do email verification as they register, they simply have a reminder that they should verify their email, but otherwise they can use the website normally. This is very good for UX, since the user can immediately start using a website and not wasting time to do email verifications etc. before he knows whether he will keep using this website or not.
So the question I wanted to ask is the following:
Suppose a malicious user writes a program that will keep registering users with valid usernames and valid(syntactically) emails.
This will eventually cause lost of trouble if not correctly managed:
the database will eventually run out of ids for users
This will create lots of records, thus eating up space
More user records, means more lookup time
So, I'm really curious how all this is managed, if at all.
NOTE: most of websites I'm talking about, do not use CAPTCHA(bad for UX), so they manage the issue in some other way, again, if at all.but neither the solution is to delete the record if the user hasn't confirmed his/her email in a time term. For suppose user looses Internet connection[, or forgets, or anything else] the last day he has to verify email. So the user will loose his/her account and just forget about that website. So this is not a solution. not sure about IP limitations. But suppose that is an Internet cafe and users keep registering. And there are dynamic IPs these days. Is limiting the registration to some amount of time a solution? But how do I know when the last registration occurred if the IP keeps changing. So how is this issue solved?
This is not really an SO problem. This site is more focused on solving issues with actual code rather than ways to solve a generalise problem.
That said, the current patterns seem to be...
Require more information. By having more information, you can de duplicate accounts. That said, in your scenario repeated accounts with the same email address should be easily consolidated. This doesn't prevent bots from registering many accounts with different addresses, but adding more requirements, such as address and phone number make it increasingly differcult to match data sets to your validation.
Validate via email. Contrary to what you suggest, this is still quite common and a good means to weed out genuine users with interest in the site from the chaff.
The other option is a federated authentication service such as Facebook, Twitter, Google+. These provide the UX you seek, but without it being your problem to validate.
From your comments that these changes aren't an option...
Your other option is to look at something server side. This will be along the lines of blocking by IP address. The problem I'd have with this is that the user is unaware, at least with the other options presented the user isn't going to get denied based upon something that happens backend. These measures can still be easily circumvented. An IP block can only be implemented for a short period of time, so the rogue registrations just need to delay long enough or more likely flip between different IP addresses.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Recently I installed a certificate on the website I'm working on. I've made as much of the site as possible work with HTTP, but after you log in, it has to remain in HTTPS to prevent session hi-jacking, doesn't it?
Unfortunately, this causes some problems with Google Maps; I get warnings in IE saying "this page contains insecure content". I don't think we can afford Google Maps Premier right now to get their secure service.
It's sort of an auction site so it's fairly important that people don't get charged for things they didn't purchase because some hacker got into their account. All payments are done through PayPal though, so I'm not saving any sort of credit card info, but I am keeping personal contact information. Fraudulent charges could be reversed fairly easily if it ever came to that.
What do you guys suggest I do? Should I take the bulk of the site off HTTPS and just secure certain pages like where ever you enter your password, and that's it? That's what our competition seems to do.
Here's the issue, and why banks are still horribly vulnerable: their landing page is HTTP, so it can be man-in-the-middled. Then they have a link to the login, and the login page is HTTPS.
So if you go directly to the login page, you can't be Man-in-the-Middled. But if you go to the homepage/landing page, since I control that, I'm going to rewrite the login page link to be HTTP. Then I'll do a SSL handshake with the login page, and send you (the user) the insecure version. So now you're (the user) doing all your sensitive transactions - and the server thinks it's HTTPS - and I'm in the middle doing shenanigans.
This is a very hard problem to solve completely because it goes all the way down to the DNS level on the server-side, and all the way down to default actions in browsers on the client-side.
As a content provider, you could try putting in javascript to check that the secure areas of your site are being accessed securely (and hope that I, as a cracker, don't remove that js before forwarding it). You can also include your happy "Please make sure this site is accessed via https" banners.
As a user, NoScript has an option to make sure sites are in HTTPS.
There's a new technology (I believe it's a marker on DNS entries maybe?) not supported by all clients/servers that lets a server opt in and say it is only accessible via HTTPS and to die a fiery death if it's being MITM-ed. I can't for the life of me recall or able to find it on google though...
I would take the bulk of the site off HTTPS with some exceptions of course:
Any checkout or account editing screens.
Any screens that would display "sensitive" information.
To deal with the session hijacking issue, I would add another layer of authentication where you prompt them for their username and password again at checkout or whenever they try to view/update account information - basicly whenever you make a transition from http to https.
Yes, I would just use SSL to secure important elements such as input fields, passwords, etc. I believe that's what most sites do, including online banking sites.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I would like to do something like play.clubpenguin.com.
What it does is that, when you visit the site, maybe using firefox or IE, if you opened a new tab or use other browser, when you visit that site again, it will show something like: "Please close the other browser that opened this page" or something like that.
How to do this? (Its client's request)
More information: The site is Flash site
EDIT:
Ok, i think this is a tough question, well, in general, Can this be done using php, mysql and JS?
Each time you serve the flash page to the user, generate a random token. Embed this token somewhere in the page, for example as a flashVar. Also, store the most recently generated token in the user's session.
Whenever the flash posts something back to the server, post the token as well. If the token does not match the token stored in the session, reject the post.
That way, only the most recently generated version of the page will have the ability to communicate with the server and if the user opens multiple versions of the page only the most recent will work.
This technique should work even if the user opens extra browsers on other machines. It doesn't use IP addresses to establish identity. And there is no chance that a user will somehow be 'locked out' permanently because every time they open the page again you reset the stored token.
It's a similar idea to the way some frameworks insert a validation token into forms to prevent Cross-site Request Forgery attacks.
try using the below code:
window.onload = function(){
if (document.cookie.indexOf("_instance=true") === -1) {
document.cookie = "_instance=true";
// Set the onunload function
window.onunload = function(){
document.cookie ="_instance=true;expires=Thu, 01-Jan-1970 00:00:01 GMT";
};
// Load the application
}
else {
// Notify the user
}
};
The code will restrict the user to open one browser tab at a time and during browser refresh(current tab) the code will not show any alert. Copy pasting the same URL in new tab will not be allowed the user to open. for more info try this
If you want to forbid access with 2 different logins, you can enforce a rule that lock on a given resource.
The client IP could be one of this lockable ressource: only one session allowed for one given IP address. That would reduce the cheating to people that have multiple public IP addresses. People that shares public IP through proxy would have problem.
I don't see what other lockable resource you can use easily.
A few options spring to mind...
When they first open the site, you'd need to store the user's current state in a cookie or similar, which you'd check for every time you open the site. If the state is Active, then it means they have another window open. The problem in ensuring that the state is cleared when they leave the original site window - you'd need to listen for the window.onunload event, and clear the state at that point - but you can't 100% guarantee this will happen.
Otherwise, you could place a script on the site which pings a server script every n seconds, notifying the server there is a window open for that client, and prevent new windows being opened until there is a lapse in pings.
To get more complex, you could maintain a persistent connection between the server and client (via sockets or similar), which would keep note of the same. Less calls from the client, a bit more complex to set up. See http://www.kirupa.com/developer/flash8/php5sockets_flash8.htm for basic info on flash + sockets.
Given you're working with Flash, you could look into Local Shared Objects (flash cookies) to store the state. Still possible to miss the unload event, but at least the cookie is persisted across all browser sessions and browser types.
Option 3 is the best IMHO.
Solution:
Response your clients request with a NO, because you are the webdesign guru that knows what's the best for the client's visitors. the website doens't have to appeal to your client but the client's visitors. and when they are limited so hard on their own computers they are everything but satisfied.