I have a use case where I need to be able to access my site from the local server. Specifically, it's for a HTML-to-PDF export of parts of various pages, but this would be nice for testing parts of the website as well.
The problem is that we have a login splash page, which needs to be dealt with before I can access any parts of the website. It would be really nice if I could just call a command "wkhtml2pdf 'localhost/[myurl]'" and have it PDF some stuff, but it hits this splash page.
Is there some way that I can perma-persist just one single session on the server? Or enable login-less access from localhost? Or could I just add a new Apache entry that accesses our site, whitelists only localhost and somehow circumvents the login?
What's the best solution?
You can pass your session cookie as parameter in wkhtml2pdf to solve your problem.
You can also execute it from a php file like this.
exec("wkhtmltopdf --cookie '{$cookieName}' '{$cookieValue}' http://example.com");
Soliciting feedback on this solution now:
I whitelisted localhost via $_SERVER['REMOTE_ADDR'] in the login scripts to bypass the usual user authentication and get an automatic localhost-user login. The server is running, however, on a university LAN, so the LAN maybe really big, possibly enabling bidirectional TCP spoofing.
Should I be worried about this, or does someone need admin rights on the routers or something? I trust the IT folks, but not others.
I realize that this sounds like a separate question, but I feel that security relates to whether or not this is a good solution.
Related
I am very confused, so please bear with me on this one.
I have a CakePHP web application (v3.8) and for some reason, it does not have a /http/ folder...I didn't develop the base part of the app, and for reasons I can't go into, I can't contact the developer.
This usually does not matter since the site works great! My issue is that we run IP logging so users can see IPs that have logged into their accounts. We started using Cloudflare, and now we are logging Cloudflare's IPs instead of actual user IPs. My research brought me to this page, but the file referenced that I need to change does not exist. The file that needs to be changed is /http/serverrequest.php, and the file does not exist.
Any help would be appreciated, I am a bit over my head with this one, but it seems like if I can find (or create) that file, and set the proxy setting to true, the IP logs will work. My main concern is if I am missing something and that isn't a good solution for whatever reason, which is why I am asking for help! Thanks again in advance!
Thanks to ndm's comment, I found the file in /vendor/cakephp/cakephp/src/Http and was able to make the changes there.
I'm building an online dating website at the moment.
There needs to be an admin backend to the site to approve users/photos etc.
I can add this admin part of the site/login etc to the same domain.
eg: www.domainname.com/admin
Or from my experience with PHP CURL I can put this site on a different domain and CURL the requests through.
Question: is it more secure to put the admin code/site on a completely different domain? or it really doesn't matter if it sits on the same domain? hacking/security is the really point of this.
thx
Technically it might be more secure if you ran it from a different server and hosted it on a subdomain using a different IP/vhost, or use a proxy mod for your webserver (see Apache mod_proxy) to proxy requests from yourdomain.com/admin to admin.otherdomain.com and enforce additional IP or access control using .htaccess or equivalent to access the proxy url.
Of course, if those other domains are web accessible, then they are only as secure as the users and passwords that use them.
For corporate applications, you may want to make the admin interface accessible from a VPN connection, but I don't know if that applies to you.
If there is a vulnerability on your public webserver that allows someone to get shell access, then it may make it slightly more difficult to get administrative access since they don't have the code for the administration portion.
In other words, it can provide additional security depending on the lengths you go to, but is not necessarily a solid solution.
Using something like cURL is a possibility, but you'd have far less troubleshooting to do using a more conventional method like proxy or subdomain on another server.
I used to work for a bank, that had a very cool feature in it's intranet. Once you logged in your computer, there were global variables set in PHP through Apache, and they contained the identity of the user that was logged on on the computer. Now I'm at a new job, and I'm wondering, how this thing worked! I would like to implement this kind of thing once again.
What I'm working with here:
FreeBSD server, version is unknown to me.
Apache 2.2 web server
PHP 5, some custom compilation, that for various reasons, I can't upgrade or modify.
MS AD
All of the users logging on to their computers are using active directory, all are in the same domain.
What I used to have was something like this:
echo $_SERVER['username']
which would print the username of the user currently logged in.
Could someone explain, how this could be done?
P.S. If any of my server settings are not what is required, say so, because then I will have a reason to ask the bosses to give me one of my own, with more control.
There's lots of ways this might be implemented. However a lot of them depend on having control over the client as well as the server.
Obvious sources of data include:
NTLM
Client side certificates
The Ident protocol (not very secure without the encryption extensions)
A long lasting cookie (again, not secure)
HTTP authentication methods
However none of these explain how the value appeared in the session - this must have been implemented within the PHP code.
So without knowing how it was implemented at your previous site we can't tell you:
Whether it was secure and correctly implemented
how to replicate the behaviour
Given your resource list, while it would be possible to implement authentication based on direct LDAP calls, passing the username and password through your application, I would strongly recommend using (e.g.) openId - but restricting the providers to just your openid provider - which would use the MSAD as the backend.
I did not understand correctly the question, so I edit my post...
you could use apache auth, you can make auth by ip's or hostnames
http://httpd.apache.org/docs/2.0/en/howto/auth.html
There is this PHP script on my website which I don't want people to be able to run by just typing its name in the browser.
Ideally I would like this script to be run only by registered users and only from within a Windows app (which I will have to provide). Can this be done ?
Alternatively, how can I protect this script so that it can only be called from a specific page or script?
Also how can I hide the exact URI from appearing on the address bar?
Thanks !
If you are running Apache for your webserver, you can protect it with a username/password combo using .htaccess. It takes a little configuration if your server is not already configured to allow .htaccess. Here are the Apache docs.
If you need authentication based on application-specific factors, you can put something at the top of your script like
<?php
if(!$user->isLoggedIn()) {
// do 404
header('HTTP/1.0 404 Not Found');
}
Do you have a question about how you would implement isLoggedIn?
You can also use mod_rewrite to rewrite URIs, and those directives can go inside your .htaccess as well. mod_rewrite can rewrite incoming requests transparently (from the browser's perspective) so a request for /foo/bar can be translated into secret_script.php/foo/bar. Docs for mod_rewrite.
However you decide to implement this, I would urge you to not rely solely on the fact that your script's name is obscure as a means to secure your application. At the very least, use .htaccess with some per-user authentication, and consider having your application authenticate users as well.
As Jesse says, it's possible to restrict your script to logged in users. There are a large number of questions on this already. Search for PHP authentication.
However, it is not possible to restrict it to a single application. It is fairly simple to use a program like Wireshark to see exactly how the program logs in and makes request. At that point, they can reproduce its behavior manually or in their own application.
There are a variety of different ways that you could go about securing a script. All have pluses and minuses, and its likely that the correct answer for your situation will be a combination of several.
Like mentioned, you could lock down the account with Apache...it's a good start. Similarly, you could build a powerful 'salt-ed' security system such as this: http://www.devarticles.com/c/a/JavaScript/Building-a-CHAP-Login-System-An-ObjectOriented-Approach/ If you use SSL as well, you're essentially getting yourself security like banks use on their websites--not perfect, but certainly not easy to break into.
But there are other ideas to consider too. Park your script in a class file that sits inaccessible via direct URI, then do calls to the various functions from an intermediary view script. Not perfect, but it does limit the ways that someone could directly access the file. Consider adding a "qualifier" to the URL via a simple get--have the script check for the qualifier or fail....again, not a great solution on its own, but one additional layer to dissuade the bad guys. If you have control of who's getting access (know exactly which networks) you could even go so far as to limit the IP's or the http referers that are allowed to access the file. Consider setting and checking cookies, with a clear expiration. Don't forget to set your robots file so the browsers don't stumble upon the script your trying to protect.
A while back my company did a membership app using Delphi on the front end, talking to php and MySql on the backend....it was a bit clunky given that we were all web application developers. If you're so inclined, perhaps Adobe Flex might be an option. But ultimately, you'll have to open a door that the application could talk to, and if someone was determined, theoretically they could dig through your app to find the credentials and use them to gain instant access to the site. If you're going the desktop app route, perhaps its time to consider having the app avoid talking to an intermediary script and do its work on the local machine, communicating the db that sits remote.
you can use deny access on .htaccess on a folder with a php authentification that will redirect to those php file
Initially I had the issue reported in this question.
Now, what I noticed is that there are some browsers that accept the password, and there are some which don't. Difference? For some reason the cookie is generated when I log in into the Administration module, but it isn't when I write down the password to access the page, forcing it to simply reload.
I can see the cookie created for the log-in, but I can see none for the password-protected Page.
These happens on Internet Explorer, both version 7 and 8; only on some machines, though, but most of them fail this. I already tried white-listing the URL, and even letting it accept ALL cookies, to no avail.
What may be the cause? If perhaps it's got something to do with question above, please help me!
Thanks in advance.
PS: If you know of another, cookie-free method to make a simple authentication, please link me to it. Thanks. Oh, and by the way, this is inside an Intranet with static, class C IPs.
Assuming you're on an Apache server, consider this authentication module for Wordpress that allows for a far more flexible approach:
http://wordpress.org/extend/plugins/http-authentication/
This module allows you to Bypass WordPress' normal authentication and use Apache's authentication instead - So pretty much any auth you'd like to use.
You can find more information on Apache Authentication methods here:
http://httpd.apache.org/docs/1.3/howto/auth.html#database
I've pointed at the database section as I'm assuming you'll want to use a database to authenticate.