I'm developing an enterprise cloud application and am addressing the security issues that I will face when using the PHP LDAP library to connect to customer networks to retrieve user objects.
Firstly there's the issue that my clients will have to open up their network to my webservers which, to many, is a huge security risk. Most would even say no to creating firewall rules allowing LDAP queries from my public IPs only.
Secondly the connection would have to remain available at all times so that my application can poll and detect new, disabled and deleted user objects. This further increases the risk factor for my clients.
The third issue is ensuring I only receive read rights to my clients AD server - how can I ensure that my clients do not accidentally give us write access to their AD? Can I, with PHP, query the permissions of the domain account provided and, if write is included, refuse to accept/store the credentials?
Does anyone have any better suggestions? I can establish an API on my end to listen for and accept instructions from a script my clients can host but that's a pain in the ass - definitely fixes up the security issues though.
There are so many ways of connecting to an LDAP server but not many articles about the best way of synchronising with an LDAP server in a private network from a server on the public network.
Advice desperately needed :)
Thank you!
Too many vauge statements, but here is a try.
The third issue is ensuring I only receive read rights to my clients
AD server - how can I ensure that my clients do not accidentally give
us write access to their AD? Can I, with PHP, query the permissions
of the domain account provided and, if write is included, refuse to
accept/store the credentials?
Sure, why not. But you may have rights to your entry but not others.
Does anyone have any better suggestions?
I could not even imagine getting access to any, and certainly not large, organizations LDAP over the Internet. Even if it were secure as an API. You really need an API interface like OAuth or OpenID Connect.
Related
Can anyone share me any idea (free) that I can make my Laravel Application (costumer website) usable to only single IP or domain?
After I host the application into my client's end, I want my code to be secured from being used again for other projects.
I want to prevent my client from re-publish my code
for example: remote confirmed from my web service for Client IP (costumer website)
After I host the application into my client's end, I want my code to be secured from being used again for other projects.
What you're looking for is a legal protection, not a technological one.
This is related to the "problem" of client authenticity in that you cannot generally control the contents of the computer that's communicating with you. Any copy-protection mechanisms you install will be trivially bypassed. (I work with cryptography; I've seen a lot of attempts to be clever, and none of them have ever stopped me from bypassing or disabling them.)
Can anyone share me any idea (free) that I can make my Laravel Application (costumer website) usable to only single IP or domain?
The way that's worded sounds like you're asking StackOverflow to give you free work (or point you to a free alternative to snakeoil solutions like ionCube) which is not what this website is for.
This might be a stupid question but I need to explore every option and can't gleam much from google on this one. Hope this is not too conversational.
I'm considering options to secure my php/mysql based admin system. One thing i've thought about is ip whitelisting with .htacess and only allowing my client access:
allow from xx.xx.xx.xxx
But I'm wondering if another method might be to not have the admin system installed online at all. Would it be possible to run the admin php locally (using wamp) and then have it connect to a live database?
Is this crazy?
Can I assume that your application is not hosted at your client's? Because if it is, then you can simply put the real application in a DMZ facing the internet and the admin application in the intranet without access from the internet.
If the application is not hosted at your client's, then your IP-based approach looks good. But you should not rely solely on the IP protection as an authentication mechanism, you should also secure the admin application with a login form asking for username and password. If you want to be super carefull, you could consider using two-factor authentication (token or Google Authenticator).
As jraede already pointed out, a local install with a remote database would be a pain in the butt to maintain. Also (and foremostly) a remote database would imply that you need the database to be accessible from the internet. That should be a security no-go if you can avoid it.
I roamed the site for this question using the search engine, and I don't think it's out there. If it is, apologies in advance and feel free to point me to it.
Here is my scenario:
I am setting up a web application, Moodle if anyone is familiar with it, with Apache, MySQL, and php on Windows. Moodle supports enabling SSL for login, but then reverts to regular http after login is established. This is running on an internal network with no connection to the outside world, so no Internet access through this network. All users who use the network have logins, however there are some generic guest type logins with certain restricted privilages. Currently the MySQL database is not encrypted.
My question is this:
If my users do an SSL login, and the system then reverts back to http for the remainder of their session, how vulnerable is the data that is transferred back and forth between the browser interface and the database?
I would perhaps prefer to have all the data encrypted, but I am not sure how bad the performance hit would be to do that, so any suggestions concerning that would be appreciated too. Although I will be extending the functionality in Moodle, I don't necessarily want to have to change it to encrypt everything if already does.
I am new to the world of IT security, and my DBA skills are rusty, so if you give me an answer, type slowly so I can understand! ;)
Thanks in advance!
Carvell
A few things.
The fact that the data in the DB server is not encrypted in no way is a factor in the communication between the User and the Web Server. It is a concern obviously for communications between the web server and the database server.
Your risk point between user and web server is in that packets could be sniffed if a person was able to interject in the middle of the communication chain. However, this risk is mitigated by the fact that your on an internal network.
Therefore, unless you are VERY concerned about the other people in your organization, you are more than likely ok. However, if it is really sensitive data, you might do ALL communications via SSL to ensure that it is transmitted securely. IF you are this concerned, then I would also look at the security of the DB and the communications from DB to webserver.
My concern would be how your authenticated sessions are propagated.
Generally a session works by setting a cookie or appending a session id to any URLs presented by the web site. Once a log-in has been established, often the credentials aren't needed any more, as a session is then linked to the user and deemed to be authenticated, and the existence of the session itself is proof of a successful authentication.
However, as previous posters have mentioned, local network traffic can be available for sniffing. If someone sniffed a session id, they could recreate the cookie or urls using the session id, and simply access the site as that session user, even changing the user's password if that option was available.
I would say that your decision here rests on the security of your sessions. If you have some mitigating factors in place to make sessions difficult to replicate even if a session id is compromised (ie. comparison to ip addresses, etc), or your user accounts are relatively secure from a compromised session (eg. require current password to change account settings), then perhaps SSL after login isn't required. However, if you have doubts and can afford the performance hit, then having SSL throughout the site will guarantee that your sessions can't be compromised (as far as you can guarantee SSL, anyway).
With no internet access to this network, the only thing that could potentially happen is someone else (who is already on the internal network) snooping on another user's HTTP traffic. If someone were to actually do that, and you aren't using SSL, they could read all the data that your website is sending/receiving from that user. But is that actually a concern?
Since you are on an internal network turning on SSL for the whole site should not be that bad performance wise, although it is probably unneccesary.
At the very least, you should encrypt the data in your database.
All sensitive data should be encrypted when transferred over an insecure wire. If you just transfer login details over SSL, all your data is still vulnerable to eavesdropping.
Since the data's not encrypted, anybody with sufficient network access (i.e. physical access) can read the data passing back and forth from server to browser and back. As long as everyone who has physical access to the network also has authorization to read the data, you're probably alright. If any of the information is sensitive, and should be restricted to being viewed by a subset of people who have physical access to the network, then you need to encrypt it.
Anyone on your network would be able to see everyone else's traffic with a network packet sniffer like WireShark. The connection between your web server and MySQL is also in cleartext. MySQL may not actually send passwords in cleartext; it may be a hash, for instance.
If you are really trying to be paranoid, you may not need to run your app over HTTPS. There are other lower-level possibilities like IPSec. Since this is an internal network, you can probably get away with implementing this on all workstations.
Not much to add to the above correct responses. But, one think you can do is use a Threat Modeling tool for your application. That will inform you on the types of threats you are exposing your data to by not using transport level encryption (TLS/SSL). Once you understand the threats, you can decide on an appropriate risk mitigation plan.
Is it possible to use the users windows authentication (setting in iis) for database connections in PHP?
This is possible in the .NET world through a technique called "impersonation". Does this also exist in the PHP/IIS world?
EDIT: The Database I am using is MS SQL Server 2005.
If you can authenticate the PHP application with Keberos, you can use kerberos Delegation to pass the credentials to the secondary server.
Ken Schaefer has a whole series of blogs on Kerberos, including this article on delegation.
Impersonation through Kerberos is the most secure answer, as well as the simplest to administrate. Having separate 'synthetic' users when accessing resources like databases means you basically bypass all possibilities for database authorization, get duplicate points of access administration, and that you get zero traceability at the database level (you just see that MySyntheticUser tried to access something, not who was behind it).
Having said this, I should warn you that Microsoft's Kerberos isn't always as straightforward as you would expect. We've had significant trouble getting it to work between pure .NET solutions, IIS, SQL Server 2005, AD domains and Internet Explorer. Most of it was down to getting trust configured exactly right. Also, while I'm not a PHP developer myself, I find some indications that you may have trouble accessing Kerberos library functionality. Find out what support you can get for SSPI. Also, your PHP process must have the necessary permissions to impersonate users, which I believe can be administered through IIS.
I would not necessarily expect all of this to be straightforward or easy, particularly as Microsoft has few incitaments to support non-Microsoft languages and platforms.
Must each user be verified separately? If not, you can set IIS to impersonate one person.
I know that you can supply the login name and password that you want associated with your ODBC connection if you create it through System DSN. I assume that the login un/pw can be windows user accounts.
Doing it that way seems to limit you to a predetermined account.
It might be possible to create a group, add the desired users, password protect the directory and only allow the group access to the directory.
You didn't say which database you're using though. If you are using MS Access, I know you can hide your database passwords. See my comment on another post.
Which way are you running IIS on PHP? As a standalone CGI or ISAPI?
My preferred solution would be to have a separate user on SQL Server for the access, instead of trying to force the IIS to run as an impersonated a user which is fine for development machines but not so good later on for production or even staging.
But if you're using FastCGI, it is possible to impersonate a user that the process is run by with the configuration file from what I remember, which passes the user logged in's credentials.
What is the best way to secure an intranet website developed using PHP from outside attacks?
That's a stunningly thought-provoking question, and I'm surprised that you haven't received better answers.
Summary
Everything you would do for an external-facing application, and then some.
Thought Process
If I'm understanding you correctly, then you are asking a question which very few developers are asking themselves. Most companies have poor defence in depth, and once an attacker is in, he's in. Clearly you want to take it up a level.
So, what kind of attack are we thinking about?
If I'm the attacker and I'm attacking your intranet application, then I must have got access to your network somehow. This may not be as difficult as it sounds - I might try spearphishing (targetting email to individuals in your organisation, containing either malware attachements or links to sites which install malware) to get a trojan installed on an internal machine.
Once I've done this (and got control of an internal PC), I'll try all the same attacks I would try against any internet application.
However, that's not the end of the story. I've got more options: if I've got one of your user's PCs, then I might well be able to use a keylogger to gather usernames and passwords, as well as watching all your email for names and phone numbers.
Armed with these, I may be able to log into your application directly. I may even learn an admin username/password. Even if I don't, a list of names and phone numbers along with a feel for company lingo gives me a decent shot at socially engineering my way into wider access within your company.
Recommendations
First and foremost, before all technical solutions: TRAIN YOUR USERS IN SECURITY
The common answers to securing a web app:
Use multi-factor authentication
e.g. username/password and some kind of pseudo-random number gadget.
Sanitise all your input.
to protect against cross-site scripting and SQL injection.
Use SSL (otherwise known as HTTPS).
this is a pain to set up (EDIT: actually that's improving), but it makes for much better security.
Adhere to the principals of "Segregation of Duties" and "Least Priviledge"
In other words, by ensuring that all users have only the permissions they need to do their jobs (and nobody else's jobs) you make sure they have the absolute minimum ability to do damage.
If it is on an internal network, why is it even possible to get to the app from the outside? Firewall rules should be in place at the very least.
The best way? Disable direct external access!
If employees need to use it (like an extranet-style site), you should make them VPN in. Through VPN you have a lot more authentication options and most of them are a great deal more secure than leaving your intranet server accessible from the internet.
Another option, and this only works if the data is public-safe, is scheduling your intranet server to push the data to another server that is externally accessible. I say push because you really don't want this server to have access to your network. Let your network server do the work.
The best way to secure it? Don't connect it to a network. Make your users physically enter a guarded room with a single console, running Mosaic.
Oh, you want it to be easy to use?
Always verify every single input that can come from an untrusted source.
Don't trust any data sources.
When storing passwords, ALWAYS store an encrypted hash of the password.
When storing passwords, NEVER store passwords directly.
Never collect or store any data that you don't actually need.
Never allow yourself to be tempted into adding additional bells & whistles.
Read everything that Bruce Schneier has written on security and encryption.
If you forget these simple rules, you could find your application starring on the front pages of newspapers everywhere, just like Yahoo mail.
I would echo #Oli and favour the VPN method if possible. However, if for any reason you need more arbitrary access than this, you should use SSL to secure any authentication. And in addition to password authentication / IP address authentication it would be well worth looking at using SSL with client side certificates.
You could only allow access from internal IPs from the php app itself. Also dont ignore the usual security and best practices. Input validation and output encoding(whitelisting only), user accounts with hashed passwords etc.