Web Service, Web Application and HTTPS Questions
September 3, 2010 3:42 AM Subscribe
I'm putting together a publicly-available web service/application and have some security questions.
I'm reasonably well-informed on topics like SQL-Injection and XSS, and I'm reading up on JSON and XML injection topics at the moment. As a software architect, I've dealt with these topics in the past.
Server security, however, is a different topic. That's always been handled by someone else on projects I've worked on in the past.
Now I'm setting up a web service that acts as a sort of broker between other, third-party web services, and I need to beef up on this area of my knowledge, as well. I'm researching the topic, but I have a question.
For the following example, myservice.com is my service and a.com and b.com are external services that my service will be communicating with, and that I'm using PHP curl to communicate with the external services.
Suppose that myservice.com does not have an ssl cert at the moment. I understand that anything submitted via a browser will be unencrypted and therefore subject to interception, but I'd like to know the following.
If myservice.com makes a curl GET to https://a.com, processes that data internally, then curl POSTs it to https://b.com, is myservice.com creating a security hole? Notice, the data will never be sent directly from myservice.com to anyone's browser.
I'm also interested in recommendations for certificate providers. I've read some of the posts regarding SSL on Ask, and most of them are pretty old. Would be great to get some updated recommendations.
I'm reasonably well-informed on topics like SQL-Injection and XSS, and I'm reading up on JSON and XML injection topics at the moment. As a software architect, I've dealt with these topics in the past.
Server security, however, is a different topic. That's always been handled by someone else on projects I've worked on in the past.
Now I'm setting up a web service that acts as a sort of broker between other, third-party web services, and I need to beef up on this area of my knowledge, as well. I'm researching the topic, but I have a question.
For the following example, myservice.com is my service and a.com and b.com are external services that my service will be communicating with, and that I'm using PHP curl to communicate with the external services.
Suppose that myservice.com does not have an ssl cert at the moment. I understand that anything submitted via a browser will be unencrypted and therefore subject to interception, but I'd like to know the following.
If myservice.com makes a curl GET to https://a.com, processes that data internally, then curl POSTs it to https://b.com, is myservice.com creating a security hole? Notice, the data will never be sent directly from myservice.com to anyone's browser.
I'm also interested in recommendations for certificate providers. I've read some of the posts regarding SSL on Ask, and most of them are pretty old. Would be great to get some updated recommendations.
sounds liek you would only be exposing traffic to someone who was doing a man in the middle attack.
Of course this doesnt apply if you store the contents locally, because in this case you would be exposing data to anybody who has access to your machine.
I bought a verisign certificate eons ago and i swore i'd never do business with them again. If you can get a.com and b.com to use you own CA you can generate self-signed certificates for nothing..
posted by 3mendo at 3:49 AM on September 3, 2010
Of course this doesnt apply if you store the contents locally, because in this case you would be exposing data to anybody who has access to your machine.
I bought a verisign certificate eons ago and i swore i'd never do business with them again. If you can get a.com and b.com to use you own CA you can generate self-signed certificates for nothing..
posted by 3mendo at 3:49 AM on September 3, 2010
You'd only have to worry about traffic being intercepted between myservices.com and the external servers. But since they're https I'm assuming these are also ssl, which is a plus. So essentially, take a look at the overall security of the subnet myservice.com resides in...are there other servers/pcs within broadcast range? Make sure these are secured if so. Use a trustworthy ISP (if unencrypted data is to be broadcast). The remaining vulnerability is on the client's end connecting to myservice.com, they will need to make sure no one is sniffing packets on their LAN.
(aside from LANs on the client's end, they can also be compromised via malware such as mebroot/torpig, tdss, etc...so it is up to them to ensure they are taking proper precautions with anti-virus and firewall security)
posted by samsara at 5:12 AM on September 3, 2010
(aside from LANs on the client's end, they can also be compromised via malware such as mebroot/torpig, tdss, etc...so it is up to them to ensure they are taking proper precautions with anti-virus and firewall security)
posted by samsara at 5:12 AM on September 3, 2010
Best answer: sounds like this will a useful guide for you: SSL in Plain English. in particular, the author seems to have had a good experience with GoDaddy's SSL certification procedure.
moreover, although you appear to have a sound grasp of a wide range of lower level concepts you seem in need of some higher-level material to tie it all together. i.e. curl GET from https://a.com, processing, and then curl POST to https://b.com sounds great, your question "is myservice.com creating a security hole?" is far too vague and unspecified. e.g.:
posted by asymptotic at 5:32 AM on September 3, 2010
moreover, although you appear to have a sound grasp of a wide range of lower level concepts you seem in need of some higher-level material to tie it all together. i.e. curl GET from https://a.com, processing, and then curl POST to https://b.com sounds great, your question "is myservice.com creating a security hole?" is far too vague and unspecified. e.g.:
- who are a.com and b.com? to what degree do you trust them? how do you even know you're talking to a.com and b.com? curl-ing over HTTPS gives you confidentiality but not authentication, as you're not verifying the certificates returned from a.com and b.com. what happens if your DNS servers get compromised or changed and a.com and b.com resolve to different IP addresses? if your immediate response is "what are the chances some random hacker will do this to me?" keep in mind the threat you face from insiders.
- how do you sanitise the input from a.com? how do you santise output to b.com?
- if you're passing information that is private to users (e.g. financial, information that can uniquely identify users) are you sure myservice.com, a.com, and b.com all satisfy local laws with respect to data privacy and protection acts? this is a big deal where i'm from, the UK.
- data from a.com is never directly sent to a user's web browser, but surely the processed data somehow affects the functioning of myservice.com. how? what happens if either/both of a.com and b.com become unavailable? what if they are compromised? if the information from a.com and to b.com doesn't "really" affect you, then why do you care about potential security issues surrounding them, and to what extent?
- ask all these questions about data flowing between you myservice.com server and users' browsers, i.e. those pertaining to confidentiality, integrity, authentication, and availability.
- Security Engineering by Ross Anderson. Non-technical, broad, but will leave you equipped with a better set of questions to ask about your setup and real-world answers from domains such as nuclear command and control to telecomms operators.
- you need books on whatever platforms and technologies you're using and how to secure them. search on places like wiley and o'reilly for books. for example, for a Linux, Apache, MySQL, PHP (LAMP stack) you could start here for Linux itself, then move onto this for MySQL, etc.
posted by asymptotic at 5:32 AM on September 3, 2010
Best answer: If myservice.com makes a curl GET to https://a.com, processes that data internally, then curl POSTs it to https://b.com, is myservice.com creating a security hole?
In both of those cases the client is libcurl and the server is elsewhere, so the presence or lack of a certificate on your server is irrelevant; what is relevant is how you configure libcurl to verify the other guy's certificate. By default when you install libcurl it comes with a CA bundle, much like how web browsers come with a preinstalled list of trusted CAs. You need to make sure that the CA that signed the certs of a.com and b.com are in that bundle. If they're not, then you either need to add them to the default bundle or you need to tell libcurl to look elsewhere, e.g. with the CURLOPT_CAINFO or CURLOPT_CAPATH options.
Obviously, you also have to make sure that libcurl is actually verifying the certificates, which is the default, but I see a lot of really terrible sample code snippets on php.net of people setting CURLOPT_SSL_VERIFYPEER to false which means "hey, I'm too dumb to know what I'm doing or to set up a proper CA bundle so I'll just disable this even though it means all the man-in-the-middle protection that SSL was designed to prevent will be completely useless."
posted by Rhomboid at 5:35 AM on September 3, 2010
In both of those cases the client is libcurl and the server is elsewhere, so the presence or lack of a certificate on your server is irrelevant; what is relevant is how you configure libcurl to verify the other guy's certificate. By default when you install libcurl it comes with a CA bundle, much like how web browsers come with a preinstalled list of trusted CAs. You need to make sure that the CA that signed the certs of a.com and b.com are in that bundle. If they're not, then you either need to add them to the default bundle or you need to tell libcurl to look elsewhere, e.g. with the CURLOPT_CAINFO or CURLOPT_CAPATH options.
Obviously, you also have to make sure that libcurl is actually verifying the certificates, which is the default, but I see a lot of really terrible sample code snippets on php.net of people setting CURLOPT_SSL_VERIFYPEER to false which means "hey, I'm too dumb to know what I'm doing or to set up a proper CA bundle so I'll just disable this even though it means all the man-in-the-middle protection that SSL was designed to prevent will be completely useless."
posted by Rhomboid at 5:35 AM on September 3, 2010
(And in case your installation of libcurl didn't come with a bundle, here's the libcurl page of the automatically generated/extracted one from the Mozilla repo that you can use.)
posted by Rhomboid at 5:45 AM on September 3, 2010
posted by Rhomboid at 5:45 AM on September 3, 2010
Response by poster: asymptotic: Thanks for the resources and for giving me some excellent additional questions to consider. Originally, my primary concern was to make sure my service didn't add any additional security risks, but I see now that I should think a bit deeper than that.
Rhomboid: Thanks for the concrete suggestions and libcurl-specific suggestions. I'll take a closer look at the libcurl options to make sure I'm doing everything correctly on my end.
posted by syzygy at 11:07 AM on September 4, 2010
Rhomboid: Thanks for the concrete suggestions and libcurl-specific suggestions. I'll take a closer look at the libcurl options to make sure I'm doing everything correctly on my end.
posted by syzygy at 11:07 AM on September 4, 2010
This thread is closed to new comments.
posted by syzygy at 3:44 AM on September 3, 2010