Web Logs and Security - Do You Know What's in Your Log Files?
So you have a new ecommerce application eh? You say you've done your homework. You are using a reputable gateway. You think you are PCI compliant. You are not storing Credit card numbers anywhere and you are using SSL (plus you have new snazzy haircut). Life is good. Hmmmm.... do you ever stay awake at night wondering if you forgot something? One of the things that you might have overlooked is the web log files. I'm sure you are aware of these files... the ones that your customer is always running reports on so he can marvel at the ip geocoding and exclaim "Well would you look at that" about the 4 people from Uzbekistan that visited the site yesterday. Web logs come in a number of flavors, but most of them are able to track the URL "query_string" variable in the log. Many of them are set up this way by default. This can be helpful to figure out traffic patterns. If you handle credit cards a certain way however, they can lead to the pit of despair. Take this example....
Credit Card Form 1
This form collects the information:
<form action="process.cfm" method="get">
Name: <input type="text" name="ccname">
CC Number: <input type="text" name="ccnum">
exp: <input type="text" name="expNum">
<input type="submit" value="go">
</form>
</pre>
- Frodo
- 41111111111111111
- 08/11
.../formscript.cfm?ccname=Frodo&ccnum=411111111111&expnum=08%2F11.
If your web server is set up to collect the query string you can go and look at the log files and you will see an entry that looks vaguely like this IIS example:
date stuff ip stuff 443 GET /formscript.cfm ccname=joe&ccnum=4111111111&expNum=08%2F11 200 Mozilla/4.0+(...useragent stuff)
See the easily recognizable CC number and expiration date? Very handy eh. This occurs whether your site is SSL secured or not. Please note, allowing CC Numbers to end up in the log files is a bad thing. Most admin types do not pay particular attention to securing the log files. Indeed, I have worked with some web hosts that zip them up into a folder (like /weblogs) off of your web root for easy downloading.
The moral of the story is two-fold. First, know what is in your web logs! Find out what's being stored there. Take a gander at them periodically and just sort of blithely peruse them with an open mind (chanting might also help) to see what turns up. Secondly, handle CC data as a POST request. Post requests are not stored in log files and will not show up in your web logs.
Finally, whenever you are working with CC numbers take the time to test all the things that are happening on the web server from start to finish. Don't neglect background processes like web logging or database logging. The end game is to know everything that is going on so there are no surprises.
7 Comments
-
I know it's not the point of your post, but who EVER submits a form using GET?
Especially with any kind of personal information? -
@michael,
Many many people use GET. I have seen this very mistake with CC numbers on more than 1 occasion. GET is convienient because it allows for testing without returning to the form to change values (just fiddle with the URL).
In addition, many languages do not have such a hard barrier between the scopes of FORM and URL. I'm thinking of JSP here ... where a form or a URL variable is treated as a "request" variable. So the whole difference between "get" and "post" may seem nuanced if you are coming from a different language.
Finally, some technologies obscure the request type making it easier to miss. For example, Fusebox merges FORM and URL data together into the "request" scope so you don't have to think about "where" user inputs come from. FB also often uses relocation. This is convenient but it makes recognizing the method you are using to send data back and forth easily overlooked.
I would also add that I get comments like this a great deal from readers - "who would ever..." or ".. if you do A or B your approach is already flawed". While I might agree or disagree with your opinion on the matter - I can't make the case by putting my nose in the air and scoffing at novice developers. I choose, rather to try and elevate the discussion where people are at. (FYI - I'm not saying you intended to 'scoff' with your tone - just that I want to carefully approach general criticism)
It is not surprising to me that you would write "...who would ever use a GET for personal information?" I would be equally unsurprised by a developer commenting "...wow ... I had not thought of that. I guess I better use POST from now on". Of course now that you have made it clear that such a developer will be summarily thrown into outer darkness I doubt I will get that comment. But I'm sure it's out there (ha). -
Wow Mark, I really didn't mean anything harsh by my comment. I'm sorry if I offended you, I was just airing the first thing which came to mind, specifically around highly sensitive information on the query string.
I more than understand that blog articles are to help those who know a lot as well as those who might not know so much.
In retrospect, I was really curious as to why anyone would use GET...not scoffing, but seriously wondering what the pro/con would be as I never use it.
I'll think before I type next time :) -
The specs say to use POST when you are changing a value. Use a GET when you are retrieving information only.
As our site doesn't collect Credit Cards or personal information, I pretty much follow the spec and use the GET method when retrieving information. -
@Lyle,
What specs are those then? You mean W3C regs? If so that is a good point. Can you provide a link for us? Unfortunately such things are so poorly adopted that they become meaningless after a while. It's sort of like using the dictionary to "prove" what a word means. A word means whatever people commonly think it means. Definitions follow usage and not the other way around. In this case, I've seen more than enough form "get" requests to make me think that at least some folks find them interchangeable.
-Mark -
@Michael,
Let me say officially that I am not upset. I was not trying to chide you in particular, and that last paragraph in the comment was an attempt to be funny. I appreciate the comments :)
-mark
Sites to Watch
Aggregators
RSS
