Hi I want to collect data for my program, I want to use PHP to do this(http://site.com/php?v="0.0.1"&n="Application"), how would I make the php page only work the my program, and not somebody else has the link.
How would I make sure the
There are various ways, but I think the one really simple is
Send a parameter some kind of token that only you and the end-script knows.
http://site.com/php?v=0.0.1&n=Application&token=SDGH36THGB
Now in your php-script, you can fetch the token parameter from request and check against something that is already saved.
if($_GET['token']==$myToken){
//its my script accessing the page
}else{
//You can show error or something
}
Now that was level-1, very simple ain't it. But what if someone comes to know about that token you're using. It can easily be exploited.
Level-2 can be something like, there's a formula which you and the script knows for e.g. it always set toekn as todays date in yymmyyddHH format.
So now the script can check this against actual time-frame whether this is correct or not. So everytime you make a request there's a different token value depending on the current-time and then the script checks this token against the current-time frame.
Now if someone comes to know about a single-token, then also he can't replicate, since that token will not work after an hour. You can decide a more complex logic yourself.
Level - 3 OAuth - it's pretty difficult, but the best part is you can already find very good implementation libraries with a quick google - https://www.google.co.in/search?q=oauth+in+php&oq=oauth+in+php&aqs=chrome..69i57j0l5.4208j0&sourceid=chrome&espvd=210&es_sm=122&ie=UTF-8
Have your users register their software, and on registration give them a user ID. Send that user ID as a get arg to the php page to identify the source of the request.
Have a multistep process for registering stats. Application requests a code from the server, application hashes code with a secret salt, and then application sends this salted hash back to the server along with all the usage data.
In both of these methods, you still can't tell if some user is manufacturing the requests. You're writing the client in Java, which means that no matter how complicated you make the verification process your end application will be decompilable and your methods will be reproducible. The first solution has the advantage of isolating stats from individual users, so if a user does end up trying to screw with your system you could prune all entries from that user.
Related
Working on an app that lets a user call someone by clicking on them. After the call, a new activity is started, FeedbackActivity, where the user enters feedback regarding the person they called which is uploaded and the server crunches the numbers over time and produces a "rating."
However, the app does not have a traditional "log in and password" behavior... (and it is important that it does not have this) so there is nothing preventing a user from maliciously entering negative feedback over and over again... or worse, loading
http://www.example.com/feedback.php?personICalled=334875634&feedback=blahblahblah
into a browser and just reloading it over and over again.
So, we need to make sure that people can only give feedback on someone that have actually called.
I had the idea of having some sort of "token" be sent to the server when the user clicks "call." Then the server saves this token.
then, when they subsequently upload feedback, it would look like:
http://www.example.com/feedback.php?personICalled=334875634&feedback=blahblahblah,&token=[same token sent prior]
This way, the server checks that such a token was ever saved, and if so, then it saves the feedback, otherwise not.
Or, better yet, there could be a secret formula known only to the server (and the app), whereby [token checked upon feedback given] is a (complex mathematical) function of [token uploaded at phone call time].
But, obviously this wouldn't be that hard for someone to figure out by looking at app source code, or observing the y=f(x) relationship over time and figuring out the formula... and there has to be a better way to do this.
I read about the Diffie-Hellman key exchange... and it seems to me there must be a way of implementing this for this purpose... but I'm not a Harvard graduate and it been a while since discrete math... and I'm not particularly knowledgable about cryptography... and the wiki page makes me head hurt!!!!
Take this diagram, for example
If anyone could tell me how the terms "Common paint," "Secret Colors," "Public Transport" and "Common Secret" translate to my scenario, I think I might just be able to figure this out.
I'm guessing that Public Transport = internet... I've got that far.
First thing, Diffie Hellman is not going to solve your problem. There are a ton of things that can go wrong in crypto, so dont play with it unless you really know that you need it and know what you want it for.
What is your real requirement? A user should be able to enter feedback only one time per call. You do not need crypto to solve this.
When the user makes a call, generate a token. Send that token to the user and also store it in the database. When the call is finished, allow the user to "consume" the token by providing feedback associated with that token. The sever verifies that the token exists in the database (and has not already been consumed). Assuming it is there, accept the feedback and then remove the token from the database (it has been consumed). If it is not there, do not accept the feedback.
You can improve things by also storing a time with the token (the time it was generated). Don't let them provide feedback if they try to consume it too soon. Expire the tokens if they are not consumed after some max life period. This prevents people from repeatedly calling a user or tokens living indefinitely in your database (DoS).
You might also restrict people by IP address. Allow a user to receive only one rating from an IP address in any reasonable time period (one day). The IP addresses can be stored along with the feedback in the database.
I am working on a system which displays the live status/stages of the system creation.
Example -: If I fill a hosting form then on my form it should display the status of the system. Like domain created, files hosted , etc in a progress bar. I want to achieve this without using data base.
Note: All the operations will be performed on a different system and my hosting form is on a different system.
Hurdles: Multiple forms can be filled at the same time.
What I have tried.
Writing steps to database and read from there.
Do curl post to a specific function. But in that case I have to use DB.
I am looking for a way where there is no db interaction required and I can see the status dynamically after filling the form.
There is 1 solutions for this:
Send and receive information using AJAX from and to server wich has installed software with API
I think this is what you want to do.
Feel free to correct my understanding of the issue, but here's how I see this at the moment.
You have a web site that has multi stage forms. So user fills the first one, then sends it, and gets the next one to be filled.
You also have a web server, probably running PHP, that handles user interaction. So whenever user fills a form, your server application proceeds with that and gives the user the next one.
Furthermore, there are multiple external servers and services that your PHP application gives orders to based on the information given by the user.
You will want to show process information from external services whenever things do proceed.
Finally, you don't want to use a oh so heavy database solution if a lighter one exists.
If I have gotten the facts about right so far, there may be a suitable solution to help you out.
To begin with, it's worth mentioning that PHP has its own session mechanism. Its data storage defaults to flat files, which may or may not be suitable for your use. Yet it requires almost no configuration or setup and offers a persistent storage, so it's by far the easiest option, in my opinion.
Note, that if the amount of information to be stored is very small, you can bypass the application data storage altogether and stick to the cookies. Read on form submit, update during the PHP process and send update the cookie accordingly as part of the response. You can encrypt the data in order to make it harder to alter by the user.
Lastly, there's this option called cache. There are multiple technologies for this when working on PHP. For instance: xcache and APC. These store information in RAM, which obviously has its downsize, since data can basically vanish at any given time - you can control this, though.
No matter the choice of data storage, the general idea is as follows:
When user first interacts with your service, create a session identifier and an approriate cookie to identify the user later on.
When user has filled the first form and sends it, read the information and either store it in the cache or in the cookie. When storing and reading information from and to the cache, either prefix or namespace it using the session identifier used by user. This way there can be multiple users using the service at any given time! When done, send the second form to be filled.
When user eventually sends the second form, read from the cache or from the cookie the information given to the first one. Now, should the information be missing, there has been an error in the filling process (or cache has been invalidated due to long time period or cookie expiration time - you will want to take these things into account, too).
So long things are going nicely, build up your information gathered from the forms. Whenever you have enough information to do so, make a request to the external service to really make things happen.
Now, lastly. You can do periodical ajax requests from the client. Therefore you get not only the forms sent, but also occasional "how is the process going?" queries. Now, whenever you receive a request like that from the browser, you can identify the user by session identifier and make a call from your PHP application to your external service, asking for a status of any kind. You then simply forward the information to the browser that has been waiting the answer all this time.
Note that you may have to store service spesific information in your cache to do this.
This setup, however, effectively gives you the ability to control data flow in your PHP application without revealing the services behind it. It's also lightweight enough to develop as it requires no additional external software for short term data storage.
I have an PHP Application. If I have logged in that application I am trying to pass the parameter as querystring through an iframe to the asp.net page.
Is there any other way to implement other than using an iframe?
Instead of having the PHP application submit data to your ASP application, it would be better if they could natively and securely share some of the data.
How?
Well, your goal is having one script tell the other that the user has been logged in, right? In PHP, this is usually done by putting something in the $_SESSION. Your ASP application can't read $_SESSION, though. You'll need to use something else.
When the user logs in, create a unique value. Maybe the result of hash_hmac over some interesting data? Whatever it is, it should be unique every time it's created and unguessable. Don't throw in things like the user's IP address or the current time.
Save the unique value to a database table that both applications can read. Also store other information that will help identify the user, such as her identifier (user_id or whatever you have on hand).
So, the PHP code that logs the user in has created this unique value and stuck it in a shared database table. Now, the PHP application should forward the user to your ASP application. Include the unique value in the request.
When the ASP application receives the request, it will look for the unique value. If it's found, it can look in the shared table. If the value is found in the table, it can then take whatever measures it needs to in order to mark the user as logged in.
Once the ASP application has logged the user in, then it should delete the unique value from the shared table. The user can be forwarded to wherever she was going in the first place.
By making the key usable only one time, and only after a successful login in the PHP application, you'll reduce the possibilities of abuse by malicious or curious users. All of the important information will be hidden in the shared database table.
Be warned that this is an overly simplistic implementation of "single sign on" and is full of caveats and edge cases. While it might work for you, it might not be the best solution. Given your question history, it looks like you've been struggling with similar issues for quite some time. You might want to give some thought into using a slightly more "industry standard" SSO mechanism. SAML is the 800 pound gorilla of SSO standards. I normally wouldn't wish it on my worst enemy, but maybe it's the thing you're really looking for here.
Also, don't use iframes, they're cookie eating disasters in some browsers.
I'm currently developing an app for iOS-devices. This app downloads data from a wordpress blog, but fetches a nonce-token first. This has been tested, and is showing to take about 2~3 seconds, which is a lot, considering it's a mobile device that should have the data ready in a few seconds. In addition to this, the data has to be downloaded as well, which takes another 4~5 seconds.
In the data-fetching-method there are several security-measures taken, for example a secret string that needs to match on both the web-server and device (of course encrypted), and some sort of simple UDID-validation + some header and useragent-tests. Is this enough, or do I really need the nonces? It's not like there is any sensitive data being passed through, and if it was, I'd of course encrypt it further.
Is it really necessary for me to use nonces?
Thank you.
If you are downloading public data, there's no need for the nonce authentication stuff.
If you are going to be modifying data on the server, or fetching data that is not public or otherwise has some kind of access control around it, then you'll need whatever mechanism Wordpress requires to gain access (which it sounds like is a nonce-based token approach).
If it's taking a few seconds to get that token, how about fetching it on app startup/resume in the background?
I have a web application that pulls data from my newly created JSON API.
My static HTML pages dynamically calls the JSON API via JavaScript from the static HTML page.
How do I restrict access to my JSON API so that only I (my website) can call from it?
In case it helps, my API is something like: http://example.com/json/?var1=x&var2=y&var3=z... which generates the appropriate JSON based on the query.
I'm using PHP to generate my JSON results ... can restricting access to the JSON API be as simple as checking the $_SERVER['HTTP_REFERER'] to ensure that the API is only being called from my domain and not a remote user?
I think you might be misunderstanding the part where the JSON request is initiated from the user's browser rather than from your own server. The static HTML page is delivered to the user's browser, then it turns around and executes the Javascript code on the page. This code opens a new connection back to your server to obtain the JSON data. From your PHP script's point of view, the JSON request comes from somewhere in the outside world.
Given the above mechanism, there isn't much you can do to prevent anybody from calling the JSON API outside the context of your HTML page.
The usual method for restricting access to your domain is prepend the content with something that runs infinitely.
For example:
while(1);{"json": "here"} // google uses this method
for (;;);{"json": "here"} // facebook uses this method
So when you fetch this via XMLHttpRequest or any other method that is restricted solely to your domain, you know that you need to parse out the infinite loop. But if it is fetched via script node:
<script src="http://some.server/secret_api?..."></script>
It will fail because the script will never get beyond the first statement.
In my opinion, you can't restrict the access, only make it harder. It's a bit like access-restriction by obscurity. Referrers can be easily forged, and even with the short-lived key a script can get the responses by constantly refreshing the key.
So, what can we do?
Identify the weakness here:
http://www.example.com/json/getUserInfo.php?id=443
The attacker now can easily request all user info from 1 to 1.000.000 in a loop. The weak point of auto_increment IDs is their linearity and that they're easy to guess.
Solution: use non-numeric unique identifiers for your data.
http://www.example.com/json/getUserInfo.php?userid=XijjP4ow
You can't loop over those. True, you can still parse the HTML pages for keys for all kinds of keys, but this type of attack is different (and more easily avoidable) problem.
Downside: of course you can't use this method to restrict queries that aren't key-dependent, e.g. search.
Any solution here is going to be imperfect if your static pages that use the API need to be on the public Internet. Since you need to be able to have the client's browser send the request and have it be honored, it's possibly for just about anyone to see exactly how you are forming that URL.
You can have the app behind your API check the http referrer, but that is easy to fake if somebody wants to.
If it's not a requirement for the pages to be static, you could try something where you have a short-lived "key" generated by the API and included in the HTML response of the first page which gets passed along as a parameter back to the API. This would add overhead to your API though as you would have to have the server on that end maintain a list of "keys" that are valid, how long they are valid for, etc.
So, you can take some steps which won't cost a lot but aren't hard to get around if someone really wants to, or you can spend more time to make it a tiny bit harder, but there is no perfect way to do this if your API has to be publically-accessible.
The short answer is: anyone who can access the pages of your website will also be able to access your API.
You can attempt to make using your API more difficult by encrypting it in various ways, but since you'll have to include JavaScript code for decrypting the output of your API, you're just going to be setting yourself up for an arms race with anyone who decides they want to use your API through other means. Even if you use short-lived keys, a determined "attacker" could always just scrape your HTML (along with the current key) just before using the API.
If all you want to do is prevent other websites from using your API on their web pages then you could use Referrer headers but keep in mind that not all browsers send Referrers (and some proxies strip them too!). This means you'd want to allow all requests missing a referrer, and this would only give you partial protection. Also, Referrers can be easily forged, so if some other website really wants to use your API they can always just spoof a browser and access your API from their servers.
Are you, or can you use a cookie based authentication? My experience is based on ASP.NET forms authentication, but the same approach should be viable with PHP with a little code.
The basic idea is, when the user authenticates through the web app, a cookie that has an encrypted value is returned to the client browser. The json api would then use that cookie to validate the identity of the caller.
This approach obviously requires the use of cookies, so that may or may not be a problem for you.
Sorry, maybe I'm wrong but... can it be made using HTTPS?
You can (?) have your API accessible via https://example.com/json/?var1=x&var2=y, thus only authenticated consumer can get your data...
Sorry, there's no DRM on the web :-)
You can not treat HTML as a trusted client. It's a plain text script interpreted on other people's computers as they see fit. Whatever you allow your "own" JavaScript code do you allow anyone. You can't even define how long it's "yours" with Greasemonkey and Firebug in the wild.
You must duplicate all access control and business logic restrictions in the server as if none of it were present in your JavaScript client.
Include the service in your SSO, restrict the URLs each user has access to, design the service keeping wget as the client in mind, not your well behaved JavaScript code.