I have a classifieds website, and a partner of us (who runs another classifieds website) need to have access to a file on our server.
The file is called 'partner.php'.
This file simply prints out some information about the classifieds on our site.
So for our partners, they would just need to access "www.domain.com/partner.php?id=1234" to have access to that information.
I am planning to add a hash to the Url, so that outsiders don't have access to the file. But I don't know how to do this...
Is there anybody who could point me in the right direction?
I have been told on phone that I can use a "32 length MD5 string and add it to the URL", but I have really no clue how to start, or what they meant by this?
Anybody know what they mean?
Examples is appreciated.
Thanks
I am planning to add a hash to the Url, so that outsiders don't have access to the file. But I don't know how to do this...
don't do it this way. A hash is fine for one-time links like E-Mail confirmation, but not for sensitive info. The hash will be present in the user's history, cache and in Proxy protocols; it can be shared accidentally.
You need to look into building proper, login-based authentication.
Some starting points:
Secure authentication in PHP
Actively maintained PHP libraries for user authentication?
Basic authentication and session management library for PHP?
Or you can use both the Hash key and IP verification. If your partner is using just one computer/server to access your file you can check the hash key and the users IP address.
$ip = $_SERVER['REMOTE_ADDR'];
Is it possible to use a different approach?
Maybe you can use a .htaccess to only allow access to the file from certain IP addresses.
Check out this page on .htaccess. There is a section called Restricting by IP Address
You could use HTTP Authentication, for example via .htaccess
Adding a hash to the URL means that you pass a GET-Parameter to the script and check it when the script starts. If the value is not the expected one, the script can simply die(); or throw some kind of error.
But I'd really NOT recommend the hash-thing, it's a bad idea.
Related
Is there a way to only let a webpage be viewed if the link pointing to it is pressed. I am sending emails to members of my organization with links that attach values to the URL so I can use phps $_GET to figure out who they are on the webpage and update appropriately. What I am worried about is individuals changing the values of the link and changing other members data. If there is a better method for doing this, I am all ears. Using a log in system is not an option.
Not exactly, no.
What you could do is include some token that you keep associated with a particular user id and is very difficult to guess, and include that in the link as well - then, when you get a GET request, you check to make sure the token matches the one you know is correct for that userid. (You'd store the "correct" tokens locally in a database when sending out the emails.)
For instance, you might have...
/modify_info_script?user_id=123&token=aSDqWEqwejk2123salskq
And then you'd have a database table or some other storage that has...
user_id token
----------------------
... ...
122 klqwkejajwie8u8213nak
123 aSDqWEqwejk2123salskq
... ...
and thus if someone tried to change the user_id in the URL, the token wouldn't match and you could reject their request. For instance, this would get rejected...
/modify_info_script?user_id=122&token=aSDqWEqwejk2123salskq
since the right token for 122 would be klqwkejajwie8u8213nak, not aSDqWEqwejk2123salskq.
This is probably the best option if using a login system isn't an option. However, you should really make sure that using a login system isn't an option at all, because user data really should be protected by a login.
This is really not the proper way to secure your site.
However, the simple fix for you is to check the "referer" header and make sure it's not blank. If it's not blank, then it came from a click (or they spoofed it, which is why this isn't secure).
The real way to protect data is to implement a login system with a set of permissions.
To check, if someone came from a link, see $_SERVER['HTTP_REFERER'].
To protect the application against link manipulation, you can combine it with a secret passphrase (only internally, the passphrase must not be known to anyone) and use md5() on the result. Attach the MD5 to the url. If anyone manipulates the url, you will know because the MD5 of "the url plus your passphrase minus the MD5" will be different.
Quite a lot password reset systems work like this so you could say it's reasonably safe provided you use long enough random token. Something like 32 chars should be fine.
Just providing the token should be enough since you don't need the user ID to check it against issued tokens in database.
/modify_info_script?token=aSDqWEqwejk2123salskqfilltill32chars
The other alternative is to have login system where use has to type in their credentials in order to change information.
Also if you really fear that someone might try to guess it, just timeout/ban users after 3 wrong token attempts. No one should be trying to type them in by hand anyway.
I've hit a dead end with this code I'm working on. I have a website where users can register and will be able to view certain pdfs when they are logged in. My question is though, how do I hide this file to make sure that only those currently logged in can subscribe. I keep track of my users with a MySQL database and have been using PHP for all the server side coding. Ideally, the solution won't involve the user having to sign in again or anything like that. I'm not necessarily looking for code (though its always appreciated :D), but any bump in the right direction would be great.
Thanks for any help you guys can offer.
if(isset($_COOKIE['login']))
{
header('Content-Type', 'application/pdf');
readfile('secret/books.pdf');
exit();
}
else
{
include('login.php');
}
The only way to secure the URL to the user is to require a login, which is something you don't want to do. (Obviously as long as the session is open via a cookie or whatever you are using, the person could access it.)
But keep in mind that once a person as the link to the PDF, they can download it and give it to somebody else. So in my opinion, you should simply focus on making it impossible for the average person to guess the URL.
In other words, simply putting the PDF on a URL that is not guessable is sufficient security given that a person can easily duplicate the PDF.
That said, if you want to lock it down a bit, you could give each user his own unique URL for the PDF. Thus if somebody does copy the URL around, you know who did it. Also, you could have URLs expire after a certain time.
That URL could be stored in the database as a url -> pdf lookup. No authentication would be required to access it.
Two thoughts on that:
1) store your PDF outside of your public readable WWW folder and include it to an authenticated user like ayush proposed
2) protect the file with a username and password using htaccess and access it with curl. cURL can provide the correct credentials without making the user re-authenticate.
I'm using SimpleCMS to allow the client to make simple textual changes to their website; however, I'm having some issues here as part of the website is password protected through setting a PHP $_SESSION variable. From this secure page, an if(!isset) is run on this $_SESSION variable to allow or disallow viewing.
Simple CMS works by logging in to www.contenteditor.net and it loads the pages into some sort of frame (I use the word frame loosely). What I want to know is, in addition to my if(!isset) test, is there a way to see if the current domain is contenteditor.net and allow them access?
Any Help is appreciated,
Dan
$_SERVER['SERVER_NAME'] and parse?
Use $_SERVER['HTTP_HOST'] to check your host address and $_SERVER['SERVER_NAME'] could also be used.
If it's in a frame, then no, there's no secure way to do this based on the domain name.
What you could do is, in your authorization code, also allow some kind of URL authorization in addition to the sessions.
When your code editing site opens the page to edit it, append that identifying information to the URL (?auth_token=abcde). You might use a database to generate these tokens from the editor application and read them from the website application, for example. Then the page can be displayed without going through a login form on the website.
two years ago I had to design a system to share authentication data across multiple domains, all of them shared the same server/db. I was able to pull this off with a complex system of cookie sharing which, to date still works.
I'm now in the process of redesigning the system and I was wondering if there are better ways to achieve this without having to write cross domain cookies.
Basically the system MUST do this.
Once logged in one site the user must be logged in all of the other site seamlessly, not only following a link, but even by directly writing the domain name on the address bar.
To my knowledge the only way to achieve this are cross-domain cookies, if there are alternatives please tell me.
Thank you very much
My Idea would be to include a login-Javascript from a third domain which gets includet in all sites. This javascript sets and reads the session-cookie and calls the current domains server via ajax with the result. (No validation should be done in the JS - this simply sets and reads the cookie)
If cross domain AJAX does not work, you can still call the thirds domain server which acts like a proxy and calls the current domains server.
The StackOverflow sites have implemented something similar to this. Check out the details at the following links.
Here is a post giving an outline of how they did it.
And here is even more detail.
For this you do have to use cookies, but you can vary what you store in the cookie. The cookie doesn't have to contain user credentials but can instead contain something more like a token that you use to "centralize" your sessions.
Easies way would be to let all hosts share a single memcached server and use the content of the users cookie as your key.
I have a download script that processes my downloads:
download.php?file=file_refrence_here
How can I prevent someone from putting a link on their site such as:
http://www.mysite.com/download.php?the_file_refrence
Apparently $_SERVER[HTTP_REFER] is not secure.
Although I am just worried about general linking not people smart enough to change their header strings.
One way would be to include a time-limited hash which is validated before you allow the download. A distributed link then only has a small window of time in which it can be used.
For example
$file="foo.mp3";
$salt="youpeskykids";
$expiry=time()+3600;
$hash=md5($salt.$file.$expiry);
$url="download.php?file=$file&e=$expiry&h=$hash";
Now, when you process such a request, you can recalculate the hash and check that the presented hash is equal: this ensures that whoever made the URL knows the salt, which one hopes is just your site. If the hash is valid, then you can trust the expiry time, and if it hasn't expired, allow the download.
You could include other things in the hash too if you like, like IP address and user-agent, if you wanted to have more confidence that the user-agent which requested the download link is the one which actually does the download.
You cannot prevent someone from linking to your page as you cannot prevent someone to write the word sunflower on a sheet of paper.
But if you want to prevent that following such a link will result in downloading that resource, you would need to authenticate the request in some way. This could be done by generating random, temporary valid authentication tokens that only your page can create.
Another way would be to, when the download link is generated, encrypt a data packet that contains the user's IP address and pass this in the URL. The download script decrypts the packet and denies access if the IP address doesn't match the current remote address.
That way, there's no time limit (not that one of those couldn't also be included if you liked), but the file can't be downloaded from any IP address other than the one that viewed the initial page.