I think that was a smart move. I'm similarly ignorant of the nitty gritty financial details of how stocks end up priced where they are priced, but I do follow a bunch of (mostly tech) companies and more or less invest/gamble on "feel" (ie, do I like and understand what they're doing, how is the stock currently priced, do those high level financial multiples make a little bit of sense against their peers and what's the competition look like). I was buying into Twilio because I'd been following their story for years and just think it's a good, solid business that will be able to grow steadily as a public company, but there's nothing steady about what's happened with the stock price. I want to pull the trigger and get out. Hard part is actually pulling it. Glad to hear you locked in the gain. Maybe you'll inspire me to do that today.
It's hard to say what is post-IPO hype and what isn't at this point.
I'm also very curious what Twilio has on its roadmap -- a post-IPO company is no longer a startup, but the whole concept of making a Python library that sends SMS messages, to me, very much feels like just a startup MVP.
It'd be interesting if they went after cell carriers with WebRTC, but even the WebRTC provider world is a pretty competitive space now with TokBox and Agora.io essentially providing the same value prop with their offerings now.
Me? I just want a China number to send SMS messages from. Get on that, Twilio!
Can confirm. No Output Caching rules defined, I am still able to reproduce crash.
[EDIT]
What is handy is that it appears that disabling "Enable kernel cache" takes effect immediately. No iisreset or server reboot required in my testing environment.
1. Passing creds via GET will show up in server logs.
2. The way REST works, you don't want to put anything in a GET which will change anything on the server (which includes generating an auth token). POST is the standard here.
edit It's better that they support POST for the auth creds in a header, but they should still be using HTTP standard authentication methods and return a 401 if unauthorized.
Also, look for already complete solutions for what you want. The whole point of REST is that you don't need to create all these query string parameters or put stuff in headers - the HTTP specs already include most of this functionality. For example HTTP already includes several authentication mechanisms[1], as does TLS[2], which are more secure (and standard!) than a form-based login.
Why should that particular book be the bible? I haven't read it, but I've flicked through it and seeing things like the suggestion that clients should "construct" URLs made me doubt its worth.
Shouldn't Fielding's original thesis be the bible?
Ok, maybe bible was used to loosely. In my experience, I found it a well written, well balanced, useful primer for real-world development of RESTful web services that also has enough depth to make it a reference I've returned to since. That's better.
You have no way of knowing what they log and don't log. If their server logs are compromised, you should be assuming their username/password database was as well.
And HTTPS requests are encrypted. The whole request, including the "GET /someurl&password=s33krit HTTP/1.1" part. As I said, using POST doesn't add any additional security to this.
I don't understand the point you're trying to make here, or the stridency with which you're making it. You in fact do know that the most popular web servers do log the URL, and do not log POST parameters or individual headers.
That's why professional security audits will ding you for putting anything sensitive in a URL.
Actually, we ding you for putting sensitive information in URLs that are used in a browser. The reason is that it will then be sent to other sites in the referrer header. When it is used for an API it doesn't matter. A security audit will check that logs are not logging sensitive information or that they are properly secured and encrypted if they do contain such information. The combination of telling users to put their password into the url and logging the url would be a problem, but not either thing on its own.
No, SomeOtherGuy. This is an HTTPS site. The referer header does not behave the way you're implying it does on HTTPS sites.
And having read and written this particular audit line item about 29074894389734897 times in the last 15 years, let me assure you that logging is clearly an issue.
The bit about how "if someone can see your logs you're already boned" is also message-board-logic more than reality. Logs are shipped all over the place. On a network pentest, one of the things you do when you pop a box is hunt for logs; even after you get root on the machine, you don't automatically have all the passwords that get stuck in the log files. Same goes for all the random LogLogic-style consoles those logs get fed to.
If you have more questions about this stuff, my contact info is in my profile --- just click my username above this comment. I just wanted to chime in to say that 'carbocation was exactly right, but my comments are now repeating themselves, and so I'm done on this thread.
I agree with your concerns. But my comment was talking about "typical server logs" and HTTPS-POST vs HTTP-GET, while yours is addressing different issues.
I addressed why what gets in logs doesn't matter: if their server is compromised you have to assume you are boned anyways. And I don't understand why is your comment would be talking about "HTTP-GET"? The API in question is dealing with HTTPS for both GET and POST requests.
I don't understand why your comments pointing out details of the http spec and common-sense security considerations are being downvoted. I guess they are coming across as overly 'stident'? Anyway, I've found them helpful. Thanks.
If you're using SSL then form data in a POST request will be encrypted. HTTP headers are always encrypted using SSL. What wasn't clear to me from the documentation is whether the 'username' and 'password' are form data, or are actually custom HTTP headers. The latter choice would certainly be a facepalm.
So will everything else, including the URI being requested
I disagree from the data I'm seeing in the access logs from my SSL-hosted site running nginx. In the logs I can see lines such as:
GET /path/script?variable=blahblah&another_variable=123
EDIT since I appear to have lost the ability to reply to comments: I disagree with SomeOtherGuy2 that The fact that it may get logged is a red-herring.
Ignoring how secure a server with a rogue user accessing it is, it's possible that there will be more than one server involved in this scenario, and central logging servers are common. Will the traffic sent to the logging server be encrypted? And what if the logging server is compromised? You're essentially storing passwords in plain text.
It's all encrypted over the network. Obviously, your servers have to be able decrypt URL strings (and everything else), or they wouldn't be able to respond correctly. I think the assumption is just that servers may by default log decrypted URLs for GET requests, but not POST requests. But, as people have noted, that's not exactly reassuring, since you have no idea how their logging is set up.
You are very confused. SSL is used to encrypt transmission between the browser and web server. Of course the web server decrypts the data it receives, otherwise it wouldn't be able to use it. I am saying you can not sniff someone's HTTPS traffic and see the urls they are requesting, so sensitive information being in the url is not a problem. The fact that it may get logged is a red-herring, as if someone has compromised the server to gain access to the logs, they can access whatever they want, your username and password included.
But you can be 99.994% sure they're writing your plan text user name and password into their logs if you're using get, and if somebody breaks in and gets them, then they have your password, even if those passwords are properly hashed in the user database.
No, I wouldn't be 99.994% sure of that at all. In fact, I would assume that if they are suggesting that people use GET, that they are in fact not logging the query params, as any security audit would catch that.
And again, if they are compromised, then they are compromised. It doesn't matter if they have logging disabled, someone who would have access to the logs also has access to either the httpd account or the root account. Either way, they can already read your plaintext usernames and passwords directly when they are being submitted. Of course, they don't need your username and password anyways, as they already have full access to the system.
Picking a comment at random to thank you for at least trying to explain to people why their assumption of what's being logged relates in no way to security.
At least one person appreciates someone taking the time to correct this rather serious misunderstanding.
"Everything in the HTTPS message is encrypted, including the headers, and the request/response load. With the exception of the possible CCA cryptographic attack described in limitations section below, the attacker can only know the fact that a connection is taking place between the two parties, already known to him, the ___domain name and IP addresses."
It's not 'compliancy' as much as they're reinventing the wheel.
REST was born out of a philosophy that the HTTP protocol already solved much of what you wanted to do.
HTTP not only solved this, but solved this a long time ago and with 'great success' (aka The Interwebs ;-)
- Authentication mechanism
- Operations (CRUD) -> GET, PUT, POST, DELETE, ...
- Caching -> Use HTTP caching mechanisms...
- Resources -> URL's
- Formats -> mime-types + use a HTTP Accept: header
- ...
They reinvent the wheel on many of the bullet points above:
custom operations, custom format handling, custom authentication mechanisms, ...
That's why this really is one of the worst implementation of an 'RESTful' API
Would you care to point out where in the HTTP RFCs it requires the use of certain methods for certain operations? The reality is, you can do whatever you like as far as HTTP is concerned. In fact, only GET and HEAD are required to be implemented, all the other methods are optional.
HTTP does not have "verbs". That is REST. Just because they aren't using a REST API, doesn't mean they are not HTTP compliant.
I'm not sure that it actually violates the letter of the law of the spec, but I think it definitely violates the spirit, based on this section: http://tools.ietf.org/html/rfc2616#page-51.
I thought that GET (along with a few other methods) were supposed to be "safe" and not result in any action on the server except possibly logging and stuff like that? Is this required to be HTTP compliant or is this more of a recommendation?
Custom headers do not REQUIRE a prefix. So the lack of prefix does not make it non-compliant. In fact, the HTTP RFC doesn't even say they SHOULD have a prefix. And RFC822 which defines headers only says that protocol mandated headers MUST NOT be prefixed with "X-". Also, there's a draft proposal to deprecate the "X-" header prefix as it does more harm than good: http://tools.ietf.org/html/draft-ietf-appsawg-xdash-02
They do not. Anyone is free to create a sole proprietorship/partnership/corporation provided that there is not national security implications ("Pam and Tom's Atomic Weapons" - Disallowed "Pam and Tom's Fighter Craft Displays" - Allowed) or confusion in the marketplace or depletion of nation resource (fishing companies, dairy companies, logging, etc). Actually, small business law in Canada is extremely well thought out. There is rarely a tax reason to incorporate, unlike other companies. For example, incorporating and paying out dividends will run you just as much tax as running as a sole proprietor. Usually. There are tricks you can pull, Turks and Caicos QA companies that reduce your profit to nearly 0 but reinvest the profits overseas. Plus IRAP funding is intense if you are large enough to float a couple salaries and you can handle mountains of paperwork.
[In Canada] There is rarely a tax reason to incorporate, unlike other [countries]. For example, incorporating and paying out dividends will run you just as much tax as running as a sole proprietor. Usually.
To elaborate slightly: The tax system treatment of dividends is set up to make "company produces a profit; company pays corporate income tax; company pays out the rest as dividends; individuals pay personal tax on the dividends" approximately equivalent to "sole proprietorship produces a profit; owner pays personal income tax". Depending on how much other income the owners have, the effective tax rate can be a few % better in either direction -- things don't line up perfectly -- but on average it works out pretty evenly.
There are, however, three common situations where incorporating produces a tax advantage in Canada: 1. If you use the company to "buffer" profits, retaining some of them in good years and paying them out in poor years (either as dividends or salary), in order to keep your personal income in a lower tax bracket (many professional corporations use this approach); 2. If you reinvest profits, since avoiding personal income taxes allows you to compound more effectively; 3. If you sell the company, since capital gains are taxed at a lower rate and in some cases capital gains on the sale of a small business are entirely tax-exempt.
It doesn't seem like there's as much incentive to misclassify employees as independent contractors in Canada. With government-provided health care and low/no payroll taxes, it isn't as lucrative to substitute contractors for full-time employees.
I've worked with plenty of contractors and few of them were 'independent' by any reasonable definition, but no one seems to care much. Every contractor I've worked with seemed to be in it to shift the risk/reward ratio in their favour, rather than because they couldn't find a full-time job.
CPP (Canadian Pension Plan) and EI (employment insurance) take around %12 of the first $50'000 annually (CPP maxes out after that) so it is pretty significant if you hire mostly median waged people.
You can do that, but it won't help. My understanding (as a non-US tax expert) is that if you're providing a service in the US you have to pay taxes in the US -- at least, last time I did consulting for a US company I had to fill out paperwork confirming that I was Canadian and doing all of the work from Canada in order to avoid all sorts of US tax paperwork.
There are similar rules to the US rules in the UK, but what we do instead is that we hire people cross border in the EU as there is no real coordination on these things between the countries. If there was they would open up a can of worms around where the tax money goes and who gets what for the services.
In fact the only sensible way to work for a Dutch company whilst living in Sweden is to have your own company or be a sole trader, even if you work 100% for the same company in the Netherlands and invoice only them.
I am not a lawyer, or an accountant, or anything like that.
My understanding is that for federal Canadian corporations a certain percentage (I think 25%) must be Canadian residents.Before doing anything like registering a company in another country it would be advisable to consult an accountant.
