I've created a php login system which saves the username as a session variable, on the server where the php is hosted.
I need to check this session before loading any pages within my stand alone phonegap (html, css & javascript) project which is hosted separately.
Is there a javascript call I can make at the start of each page to check it and then redirect it if they aren't logged in?
you should not do that, somebody could turn off javascript and bypass your check.
instead, do normal php check on eatch page. you can put check into separate file (say, check.php) and just put on etach page require ('check.php');
EDIT (reply to comment/question edit):
a) how to make your own session:
as simple as session_start();
b) how to pair it with remote session:
if (!isset($_SESSION['remoteid']))
$_SESSION['remoteid'] = sesion id that you recived as response prom remote php server.
once again, you can not do it simply with html, css & javascript. javascript can be turned off. you need php/python/ruby/etc...
needless to add that javascript can not be persistent, since it is not executed on server.
Related
Can someone confirm that the is the basic flow for PHP - HTML.
PHP runs on the server, and pre-processes the page so it can be sent to the browser.
In the browser you can run things like javascript.
So in order to pass things to PHP (from Javascript):
you need to "fetch" the php page (with post or get args)
This re-runs the php page (on the server) allowing you to process those args, generating a new "page" to send to the browser.
PHP variables aren't "sent" to the browser, but processed and inserted in the a new page that's sent out when the page is fetched.
Am I even close ?
I have a slightly strange question and I'm not sure if this could be achieved at all but anyway I'm curious to try.
I have 2 sites that are independent, lets say www.site1.com and www.site2.com.
site2 will be placed in a href in site1. The question is - is it possible site2 to be accessible only after the user is redirected to it from site1 and if the user tries to open site2 directly or thru an a href from another site different then site1 to not be able to access it?
Check for:
window.document.referrer
// Empty if User is directly loading page.
The value is an empty string if the user navigated to the page directly (not through a link, but, for example, by using a bookmark). Because this property returns only a string, it doesn't give you document object model (DOM) access to the referring page.
MDN Documentation: https://developer.mozilla.org/en-US/docs/Web/API/Document/referrer
Browser Support:
You can check for a post parameter that you set from the website 1 redirection (either through a form or plain javascript). And then set a local storage variable to check for when loading site 2.
Local storage doc
JavaScript post request like a form submit
But keep in mind this can be easily bypassed with enough html/js knowledge.
To ensure that only your website can make post parameter, you could maybe (not sure about me there): generate code (used as post parameter) on the go from webserver 1 and send them to webserver 2 at the same time (or a little before) to ensure the code received by the server 2 is really generated at server 1
Depending on the backend server you are using, you can use something called REFERRER details that will be there in the http header of the request ( for your www.site2.com page for example). This REFERRER will have the information on who referred the user to this site. You can add a condition something like if REFERRER is www.site1.com then render the page .
Here is a link to start with
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referer
I'm not sure I fully understand this aspect of site security, but seems it is a bad idea to keep PHP files on root, so we move them into a PHP folder, and we call this folder phpIncludes. Some issues that are obscure are:
1) how do I access a file doStuff.php inside phpIncludes? From javascript? Seems to be a bad idea to have my javascript tell the name of the folder where sensitive stuff is, as in:
executeAjaxCall("phpFiles/doStuff.php",success,error);
2) Or from a "master" PHP that resides on root? Can't that be tampered with for being on root?
$secretVariableThatOnlyThisPHPWouldKnow="bla"; //then check it in the included file? Does that work?
//in JS
executeAjaxCall("masterFile.php?fileNeeded=doStuff");
//in PHP
$secretVar="bla";
include("myPathString/phpIncludes/".$_GET['fileNeeded'].".php");
//in all other INCLUDEable PHP files
if (!isset($secretVar))
{
die();
}
if (!isFromThisDomain)
{
die();
}
(How do I perform last test?)
What I have in mind is: "If someone wants to get the PHP files inside folder phpIncludes they can't, but they can access them thru HTML so requests need to be validated. Is it easily doable without sessions, like generating something in master.php that doStuff.php would recognize and hence do its job? Or is sessions the way to go?"
I am actually wondering about the "no session" scenario for this frees me from the task of attempting to implement anti-session hijacking code (if I ever learn it...). On the other hand, I am also thinking:"Isnt the variable secretVar accessable/tamperable since it will be on root?"
3) Do as (2), but have master.php inside yet ANOTHER folder (lets call it "master"), making it non-root? In this case, do I access my phpIncludes folder from the master folder using getcwd()+string manipulation? Or is there a "more elegant" (lazier...) method?
3 seems magical, where the only file I have on root would be index.php, that simply starts the HTML+JS and does nothing sensitive. Or am I missing something?
It is completely irrelevant how your PHP file and folder structure is. The only thing that matters is this:
What happens when you access a particular URL?
phpFiles/doStuff.php is a URL first and foremost. It doesn't matter how you access it ("directly" via the browser address bar, via AJAX, curl, whatever else); all that matters is what happens when you access that URL. And it's entirely up to you to ensure that nothing undesirable will happen with each URL access.
Don't publicly expose any URLs which aren't meant to exist in the first place. If you have a bunch of .php files which aren't mean to be accessed directly via a URL, then don't publicly expose them. That either means that you block access to them via your web server configuration (e.g. deny all in an .htaccess file), or that you take those files out of the public webroot to begin with.
Validate all input and necessary conditions in all publicly exposed URL endpoints as necessary. The user needs to be logged in to do something? Verify that. You require certain query parameters or POST body data? Verify that. Validate and verify every incoming request on its own merits before doing anything. Whether you repeat this validation code in each file individually or do it somewhere centrally is up to you.
Split your code across multiple files as appropriate to make it reusable. See points 1. and 2., you must simply take care which files are publicly exposed as URL entry points and at which point you need to do what sort of validation.
I'm using the PHP 5.5+ password_hash() function to hash my passwords before storage in the database. So far so good.
What I am a bit uncertain of is the need of pre-hashing the password that it sent from the form to my PHP script.
Now the form submit procedure is (in short terms) done like this:
HTML file which contains the form calls the controller script in form method=".." ->
Controller script recieves the call and picks the correct function ->
function execution and storage to database.
So basically the call is sent through three files from submit to storage.
I am thinking that somewhere along the line the data could be hijacked and seen in plain view since the hashing is done in the third and final file.
Should I be worried and somehow hash the password with some JavaScript during the initial submission of the form or is it safe? The final site will most likely use an SSL certificate but still I'm not 100% sure if I am safe or not.
Your concerns about hijacking the password between controllers are superfluous :
For an attacker to hijack the password while it's passed between different controllers it would mean the attacker has to be able to read the memory of the PHP process, which would require root privileges. If the attacker has root privileges, you have a bigger problem and your solution won't save you because that same attacker can also modify the PHP files to remove your "protection".
As for hijacking the password while it's flying through the Internet, the only solution is to use HTTPS - whatever Javascript cryptography/hashing you would do is pointless since an eavesdropper is also able to alter the page while it's being transmitted and serve a modified version of it without the additional "security" you added; there are many questions about trying to secure a login form without HTTPS on Security.SE, check them out :
https://security.stackexchange.com/questions/73917/techniques-to-make-a-login-page-safe-without-using-ssl
https://security.stackexchange.com/questions/37655/build-a-secure-channel-without-ssl-tls
https://security.stackexchange.com/questions/41845/login-security-without-ssl
https://security.stackexchange.com/questions/8924/what-is-the-best-way-of-securing-a-website-logon-without-ssl-or-preshared-keys
I have a link, that when a user clicks on it, it loads a different page as normal but also executes a JS function that autofills a specific text-box on that different page. Is it better practice to use Jquery or Javascript to do this? How can I do this using either one of them?
You can't do this from the source page.
It's a security feature. Imagine if you wrote a JS function that went to an online banking page and auto-filled a bank transfer using the user's current cookie. That's why you can't.
If you control the other page then the sequence you can use is:
Save data to the server;
Go to the new page with a JS redirect;
The new page is loaded from the server;
While loading th epage the data that was saved from the server is retrieved and used to populate the text box.
So it can be done from the server but only if you save it there. The only way of doing that is using Ajax.
An alternative approach is:
Instead of a JS redirect, submit the page back to the server;
The server saves whatever data it needs to;
The server sends back an HTTP redirect to the new page;
The new page uses the saved data to construct the new page with the populated text box.
At the end of the script add return false;. This will make the page run the script without redirecting the page.
Edit: (after saw your edition).
Is it better practice to use Jquery or Javascript to do this? How can I do this using either one of them?
jQuery is a javascript library, this it doesn't matter if you use plain javascript or use jquery as long as you happy with the result.
And about what you say that you successfully manipulated a page fro the redirecter page... I don't see how it possible.