A non-technical, security-paranoid employee at work insists that an effective method of securing a website of ours, is to separate the application in to three parts; a front end, an API, and a backend management area for staff.
Both the API and the management system are on domain names that are just a random set of characters.
The application holds sensitive data, however, all of the applications are on the same server.
The problem I face is that debugging or adding features the application while it is in this state makes work extremely difficult, as it is unclear as to what part of the application does what. (There is no documentation and the previous developer has since left the company.)
He insists that future projects follow the same suite, with their own separate APIs and management areas, which I think will be unnecessary for a relatively simple application.
The second problem is that I know that security through obscurity is not necessarily security, and I don't see the point in using a domain that complicated to host part, or all of a website.
So my questions are this:
1) Is using an API like this going to carry any security benefits? Are there alternative ways that we can ensure the application and it's data is secure so that it does not compromise development speed.
2) Is using an obscure domain necessary to keep an application secure? Again, are there alternative methods that would be just as effective that wouldn't look as odd to future developers?
3) The management system is secured with a username and password. Would having the administration system be just as secure being on website.com/admin rather than randomcharacters.com?
Is using an API like this going to carry any security benefits? Are there alternative ways that we can ensure the application and it's data is secure so that it does not compromise development speed.
An API should be secured by an authentication mechanism such as an OAuth access token (AuthN). Who can do what on that API should then be determined by the claims in the access token (AuthZ). Authentication and Authorization should be thought of in these terms.
'I am this principal, I can prove this because I have a token that you have issued me and you can verify that only you could have issued it. I have a number of pieces of information that you can use to make decisions on what I'm allowed to do'
Is using an obscure domain necessary to keep an application secure? Again, are there alternative methods that would be just as effective that wouldn't look as odd to future developers?
No, using obscure domain names doesn't offer any level of security. They are just letters that are transformed into an IP address by a DNS entry - to use either my-website-address.com or hdsfiuycxzuyecgfr.com, you'd have to communicate that to someone and at that point they are equally secure!
The management system is secured with a username and password. Would having the administration system be just as secure being on website.com/admin rather than randomcharacters.com?
The questions to ask are, who are the users of the different parts of the system and who should have access to what? Is the front end application publicly visible on the internet and can it be used by various clients? Does the management system fall into the same category, or is that more of an internal tool? Identify the use cases for the components and consider whether you will secure them either by application logic, such as OAuth tokens, or infrastructure restrictions (e.g. only computers within a particular IP address range / subnet can access the management tool). It's usually a combination of both application and infrastructure security that provides the best level of protection.
Having the front end application and the management tool hosted as different applications may allow you to apply different security boundaries around them, which could be useful.
However, it's a matter of determining who your threat actors are and designing accordingly.
An obscure domain name just needs to leak once somewhere; as soon as any attacker gets wind of the domain name, it ceases to be obscure and does not provide any benefit whatsoever. If you have a public website which makes API calls to the "obscured" backend, then that domain name is already being well publicised.
No, there's virtually no point in using an obscure name for the sake of security. If your API is insecure and allows unauthorised access, that is your security weak point; not the fact that the domain name might be known.
Related
I have SAAS type application and I am providing it service to many users.
It is developed using php.
I want to know which structure is better, right now I have subdomain structure, each group is different subdomain, though all uses same code from one source.
so it like
group1.domain.com
group2.domain.com
both uses single code but behave has separate application.
Another structure is also available in which we specify group in URL and not as subdomain like
domain.com/group1
domain.com/group2
My question is which structure is better in terms of scalability and security ?
do subdomain or url structure have any security issue ?
Which is better if we need to scale and use multiple server which will be better?
I'm not going to explore the full details about scalability and security, but there is an inherent difference about how the two URL types are handled which is basically the starting point for all other considerations:
Sub-domain routing is controlled by the DNS system and therefore can be routed without requiring any input from the server hosting the site. Changes to routing have a time-lag.
Path-based routing is controlled by the web server (e.g. Apache) and therefore needs to be handled by your server or infrastructure. Changes can be applied instantaneously.
Given that you can configure multiple sub-domains to point to the same server, anything you can do in scenario #2 you can also acheive via scenario #1. Therefore, the question is what advantages do you gain from using sub-domains and what are the disadvantages.
Advantages:
Routing is cheap, as it is handled via the DNS system.
Routing is flexible - it is easy to move a particularly troublesome user to their own server if they are impacting performance of other users. With path-based routing this would require additional infrastructure.
If you offer e-mail services, each client has their own sub-domain and therefore has no restriction on mailbox names.
This will allow you to have per-client SSL certificates, rather than a single certificate for all clients (though the latter is still possible).
Disadvantages:
Adding/removing new clients is harder to automate, as it requires a DNS update.
Changes take a short while to propagate, rather than applying instantly.
Assume there are two different apps on appengine- one powered by Go and another by PHP
They each need to be able to make specific requests to eachother, purely over the backend network (i.e. these are the only services that need to make these specific requests- other remote requests should be blocked).
What is the best-practices way of doing this? Off the top of my head, here are 3 possible solutions and why I am a bit worried about them
1) Do not keep them as separate apps, but rather modules
The problem with this is that using modules introduces some other annoyances- such as difficulties with Channel Presence reporting. Also, conceptually, these 2 requests are really the only places they touch and it will be clearer to see what's going on in terms of database usage etc. if they are separated. But the presence issue is more of a show-stopper
2) Append the request with some hardcoded long secret key and only allow response if via SSL
It seems a bit strange to rely on this, since the key would never change... theoretically the only way it could be known is if an administrator on the account or someone with the source revealed it... but I don't know, just seems strange
3) Only allow via certain IP ranges (maybe combined with #2)
This just seems iffy, can the IP ranges be definitively known?
4) Pub/Sub
So it seems AppEngine allows a pub/sub mechanism- but that doesn't really fit my use case since I want to get the response right away - not via a postback once the subscriber processes it
All of them
-- As a side point, assuming it is some sort of https request, is this done using the Socket API for each language?
HTTPS is of course an excellent idea in general (not just for communication between two GAE apps).
But, for the specific use case, I would recommend relying on the X-Appengine-Inbound-Appid request header: App Engine's infrastructure ensures that this cannot be set on requests not coming from GAE apps, and, for requests that do come from GAE apps (via a url-fetch that doesn't follow redirects), the header is set to the app-id.
This is documented for Go at https://cloud.google.com/appengine/docs/go/urlfetch/ , for PHP at https://cloud.google.com/appengine/docs/php/urlfetch/ (and it's just the same for Java and Python, by the way).
purely over the backend network
Only allow via certain IP ranges
These requirement are difficult to impossible to fulfill with app engine infrastructure because you're not in control of the physical network routes. From the app engine FAQ:
App Engine does not currently provide a way to map static IP addresses to an application. In order to optimize the network path between an end user and an App Engine application, end users on different ISPs or geographic locations might use different IP addresses to access the same App Engine application.
Therefore always assume your communication happens over the open network and never assume anything about IPs.
Append the request with some hardcoded long secret key
The hard coded long secret does not provide any added security, only obscurity.
only allow response if via SSL
This is a better idea; encrypt all of your internal traffic with a strong algorithm. For example, ECDHE-RSA or ECDHE-ECDSA if available.
I am looking to add to an existing C++/Windows application the on-line storage of application files, for backup purposes and easy of application file access between multiple computers. The files are around 100k in size, and I’d estimate that each customer will want to store 1-10 of these files, but some may wish to store hundreds in different folders. I would estimate that over time several thousand customers would want to use this feature, but the average use per month would not be that high (my customers tend to use the software extensively for a couple of months and then settle to a much lower usage pattern).
The security requirements are not high (no personal or sensitive information is in the application files), but basic login authentication would have to take place. I have a user forum (phpbb), which may be the easiest place to take care of the login creation / password recovery (depending on the server used below).
I have a web server (with php & mysql), and the disk space / bandwidth should not be a problem. I do not wish to use 3rd party libraries without source, as past experience has shown this introduces bugs / problems upgrading compilers etc.
I’m aware that I’ll need both server and client software and they will need to communicate using a protocol. As far as I can tell, my options are:
Use an existing online storage provider, such as DropBox. The problem I see with this is the client side interface software (I know of SharpBox, but it is .net), and other possible restrictions on storage space, account activity etc.
Use open source online storage software, such as OwnCloud. WebDAV should be able to be used for the interface, but again there currently is no client software for OwnCloud. I did get as far as setting up OwnCloud 2 and 3, but WebDAV seemed to only be partically supported. This is my preferred solution – use an off the shelf server with decent example C++ client to get me started.
Create my own server, protocol and client front end. I could use WebDAV or SOAP for the protocol. This is my last option just because of the amount of work to re-invent the wheel, but gives the simplest, most flexible system and best chance of integration with the phpbb forum for login credentials etc.
Are there other options which meet my needs which I have overlooked?
I have two websites, one driven by ASP.NET and the other in PHP. The PHP site is hosted on a relatively inexpensive host provider ('unlimited bandwidth and diskspace for $10 a month). The PHP site also provides REST URLs which would help me in monetizing my website.
The other site (the 'main' site, as it were) is an ASP.NET website which houses the login mechanism. My goal is to allow users to log in to the ASP.NET site and then be redirected to the PHP based domain. Is there an easy and feasible solution that accomplishes this?
I have a few questions with regards to that approach:
How would I pass session information and variables from the ASP.NET Application to the PHP based application, to facilitate the aura of 'Single Sign On'?
Would a 'simple' cookie be able to handle this scensario? Or would I need to use encrypted query strings?
There is no 'sensitive' data on these sites, so securing user data isn't a top priority. The site was built 'for fun'.
Are there hosts that allow subdomains to be hosted on a different language platform than the main domain? If I had www.example.com hosted on an ASP.NET server, could I have a subdomain (forum.example.com) hosted on a PHP server? Is this possible?
Any help on this is greatly appreciated.
Although more complex, I would go with the same methodology as the OpenID spec and use the Diffie-Hellman exchange. This allows two parties with no prior trust, to establish a trust for a certain period of time.
Info for PHP
Info for VB.NET
I would go for a cookie if both sites are on the same domain. One advantage of cookies over encrypted strings is that they are automatically passed between requests and you don't have to think about them when building your urls. One downside of cookies is that they can be disabled by users.
Store the sessions in a database and create / use a session-type which is cross-platform. You might to do it yourself. But you should know that passing sessions etc between different languages like this, can be dangerous ( security-wise )
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.