>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.
Which is what I said. Logging sensitive info is an issue. Not requesting info that could be logged if you were using default settings. You will get dinged for logging sensitive info, you can either not have the info in the query, or not log the query. Either is fine.
>The bit about how "if someone can see your logs you're already boned" is also message-board-logic more than reality.
No it isn't. If you can read the logs, you are already either the httpd user or root. Hence you don't need application usernames and passwords anymore, you can just go right ahead and do whatever you like.
>Logs are shipped all over the place.
Wait, I thought we weren't doing things that a security audit will catch? Why did you change your mind now that is convenient? Rather than considering theoretical "what if they are absolutely retarded and send my username and password in the logs in plain text to internet accessible log storage servers?", why not consider the reality that if they are that stupid, they will be compromised anyways. So what is the concern here? As a user of their system, I know they are either doing things right and I am fine, or doing things wrong I and I am boned. So, exactly what we knew before the whole GET vs POST debate. Very helpful. If they are idiots, then there is nothing I can do to secure my account with them, this is why we don't use the same password for multiple services.
>If you have more questions about this stuff, my contact info is in my profile --- just click my username above this comment
I would suggest that you read the posting guidelines.
Unfortunately, very little is required to be HTTP compliant. It is almost all SHOULDs and SHOULD NOTs, and is full of vagueness. Here's a quick discussion of how bad the HTTP spec is for being strict and easy to implement: http://www.and.org/texts/server-http
Now read it. Notice how it is all "SHOULD" and "SHOULD NOT". You can do whatever you want and still be HTTP compliant. Using practices that are not recommended is not the same as being non-compliant.
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.
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.
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.
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.
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.
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
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.
They didn't. They just tried to store data on EBS volumes, you know, like they are supposed to. But EBS performance is very bad, and incredibly variable. So they would end up getting timeouts trying to write to the volumes, which broke their DB replication, which took the site offline for hours to re-replicate.
Which is what I said. Logging sensitive info is an issue. Not requesting info that could be logged if you were using default settings. You will get dinged for logging sensitive info, you can either not have the info in the query, or not log the query. Either is fine.
>The bit about how "if someone can see your logs you're already boned" is also message-board-logic more than reality.
No it isn't. If you can read the logs, you are already either the httpd user or root. Hence you don't need application usernames and passwords anymore, you can just go right ahead and do whatever you like.
>Logs are shipped all over the place.
Wait, I thought we weren't doing things that a security audit will catch? Why did you change your mind now that is convenient? Rather than considering theoretical "what if they are absolutely retarded and send my username and password in the logs in plain text to internet accessible log storage servers?", why not consider the reality that if they are that stupid, they will be compromised anyways. So what is the concern here? As a user of their system, I know they are either doing things right and I am fine, or doing things wrong I and I am boned. So, exactly what we knew before the whole GET vs POST debate. Very helpful. If they are idiots, then there is nothing I can do to secure my account with them, this is why we don't use the same password for multiple services.
>If you have more questions about this stuff, my contact info is in my profile --- just click my username above this comment
I would suggest that you read the posting guidelines.