So our security audit claims that I have to shutdown all Apache httpd methods but POST, GET and HEAD. I went to the Apache documentation and they claim you should use LimitExcept. Sounds great right, so I tried using it in all the places they allow, but it doesn't work anywhere I put it. After scouring the web I have just given up and used something really simple:
RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^(?!POST|GET|HEAD)
RewriteRule .* - [F]
Works great (with the minor performance cost)... I wish Apache would just fix LimitExcept so it could be global. Some of us don't use Directory entries like they expect.
Just thought I'd post though so that others may not have to suffer the same waste of time as myself.
Wednesday, February 1, 2012
Friday, February 25, 2011
Simple way to do a facebook like check in java
People are making this so hard. Now facebook is moving from fbml you gotta do the like check yourself instead of using the very convenient
static final Pattern FB_SIGNED_REQUEST_PATTERN = Pattern.compile("liked\":(.)");
static final BASE64Decoder BASE64_DECODER = new BASE64Decoder();
public static boolean isFacebookFan(HttpServletRequest request)
throws Exception
{
String fbreq = request.getParameter("signed_request");
if (fbreq == null) throw new Exception("No request");
fbreq = new String(BASE64_DECODER.decodeBuffer(fbreq));
log.error(fbreq);
Matcher m = FB_SIGNED_REQUEST_PATTERN.matcher(fbreq);
return m.find() && m.group(1).equals("t");
}
Tuesday, January 11, 2011
The Firesheep Problem, and How rcwilley.com Is Protected
Recently with the new "Firesheep" firefox addon that steals facebook and twitter sessions over unsecured wifi sidejacking is in the news. I thought I'd sit down and write about my solution to the problem which protects rcwilley.com sessions from being hacked.
A few years ago when I changed jobs into the web engineering business I was forced to get up to speed on session cookies and how they are used. For those of you not familiar with how cookies work here is a quicks simplified primer:
Cookies are little pieces of data that a website can send to your browser. Then whenever your browser communicates with the same server it got the cookie from, it sends it in the request. The web server can then look at this cookie and know what browser he is talking with. When you log into a website, it is very common for them to send a piece of data called a session cookie to your browser. Then every time you ask for a new page they know who you are. Now this is all perfectly secure and safe as long as you never communicate with the server over a non-secure http connection. However most websites, after using a secure https connection to send your login and password over, switch back to http for performance. They don't pass your password any more, but every request from your browser has the session cookie sent UNPROTECTED to the server. That is how the server knows who you are for the rest of your visit.
Now there is a concept of a secure cookie which the browser is only allowed to send over a secure https connection, but they are hardly ever used. This is because the user may make a request over http all of a sudden, and the server won't know who it is.
One of my first tasks was to create a single sign on kind of solution that allowed customers to log into our site and stay logged in while they moved between normal and secure pages on our site. I got it working the commonly accepted way of using the session cookie to maintain the users login credentials throughout their visit. This worked just fine, but I wanted to make sure my solution was secure when we switched between http and https.
After hunting around on the internet on ways to hack sessions I learned about sidejacking. This is when someone able to watch network traffic between a browser and the web server just grabs a session cookie and uses it to pretend to be someone else. I asked one of the top engineers at my web consultant firm how to prevent this, and he said I shouldn't worry about it because it was to hard to do a sidejack of a cookie, and no one else worried about it. I visited many big websites, and watched their cookie usage. None of them used secure cookies. Facebook and twitter were common examples of these kind of sites, so it seemed that my co-worker was right about sidejacking being a non-issue.
Basically web sites seem to be in the following camps:
1. Sites that are stateless and need no cookies
2. Sites that use https for login, but no secure cookie, risking an http connection sending the cookie in the open. These are the risky ones like facebook and twitter.
3. Sites like 2 that fortunately make you login again every time you go into a secure area. This helps.
4. Sites like 2 that make you login every time you enter a secure area, and then use a secure cookie. Amazon appears to be in this camp.
5. Sites that are completely https and use secure cookies and suffer the performance penalties. Mostly banks and the like.
My favorite kind of site is 2 because it doesn't irritate the user after they already logged in, but it is too risky. I still just didn't feel right about being a type 2 site. So for rcwilley.com I adopted a combination solution that would give me the benefits without the problems. The simple solution is to use both secure and normal cookies, and require the secure cookie whenever the user re-enters a secure area. It was very easy to implement and completely solves the problem as far as I can figure. Twitter and Facebook ought to consider this method if they don't want to go completely secure like a bank.
Now some nitty gritty details for those who care. When the user logs in, I do it over a secure request and I give them their normal session key in a normal cookie. I don't have to mess with the default behavior of tomcat at all. At the same time I also generate a secure cookie and send that as well. The secure cookie value is simply stored in their session with everything else. Thereafter they can go to an http section of the site, and back without having to re-login. Whenever they try to make a secure request from then on I just check to make sure they also sent me the correct secure cookie as well. Otherwise they have to log in again. Works like a charm.
A few years ago when I changed jobs into the web engineering business I was forced to get up to speed on session cookies and how they are used. For those of you not familiar with how cookies work here is a quicks simplified primer:
Cookies are little pieces of data that a website can send to your browser. Then whenever your browser communicates with the same server it got the cookie from, it sends it in the request. The web server can then look at this cookie and know what browser he is talking with. When you log into a website, it is very common for them to send a piece of data called a session cookie to your browser. Then every time you ask for a new page they know who you are. Now this is all perfectly secure and safe as long as you never communicate with the server over a non-secure http connection. However most websites, after using a secure https connection to send your login and password over, switch back to http for performance. They don't pass your password any more, but every request from your browser has the session cookie sent UNPROTECTED to the server. That is how the server knows who you are for the rest of your visit.
Now there is a concept of a secure cookie which the browser is only allowed to send over a secure https connection, but they are hardly ever used. This is because the user may make a request over http all of a sudden, and the server won't know who it is.
One of my first tasks was to create a single sign on kind of solution that allowed customers to log into our site and stay logged in while they moved between normal and secure pages on our site. I got it working the commonly accepted way of using the session cookie to maintain the users login credentials throughout their visit. This worked just fine, but I wanted to make sure my solution was secure when we switched between http and https.
After hunting around on the internet on ways to hack sessions I learned about sidejacking. This is when someone able to watch network traffic between a browser and the web server just grabs a session cookie and uses it to pretend to be someone else. I asked one of the top engineers at my web consultant firm how to prevent this, and he said I shouldn't worry about it because it was to hard to do a sidejack of a cookie, and no one else worried about it. I visited many big websites, and watched their cookie usage. None of them used secure cookies. Facebook and twitter were common examples of these kind of sites, so it seemed that my co-worker was right about sidejacking being a non-issue.
Basically web sites seem to be in the following camps:
1. Sites that are stateless and need no cookies
2. Sites that use https for login, but no secure cookie, risking an http connection sending the cookie in the open. These are the risky ones like facebook and twitter.
3. Sites like 2 that fortunately make you login again every time you go into a secure area. This helps.
4. Sites like 2 that make you login every time you enter a secure area, and then use a secure cookie. Amazon appears to be in this camp.
5. Sites that are completely https and use secure cookies and suffer the performance penalties. Mostly banks and the like.
My favorite kind of site is 2 because it doesn't irritate the user after they already logged in, but it is too risky. I still just didn't feel right about being a type 2 site. So for rcwilley.com I adopted a combination solution that would give me the benefits without the problems. The simple solution is to use both secure and normal cookies, and require the secure cookie whenever the user re-enters a secure area. It was very easy to implement and completely solves the problem as far as I can figure. Twitter and Facebook ought to consider this method if they don't want to go completely secure like a bank.
Now some nitty gritty details for those who care. When the user logs in, I do it over a secure request and I give them their normal session key in a normal cookie. I don't have to mess with the default behavior of tomcat at all. At the same time I also generate a secure cookie and send that as well. The secure cookie value is simply stored in their session with everything else. Thereafter they can go to an http section of the site, and back without having to re-login. Whenever they try to make a secure request from then on I just check to make sure they also sent me the correct secure cookie as well. Otherwise they have to log in again. Works like a charm.
Friday, June 11, 2010
IPhone 4's Great New Camera... What is a backlit sensor?
The new iPhone 4 has a great new backlit camera sensor. Most people don't understand why this is nice so I wrote up this little description for the TII Podcast I listen to. A major factor in my recent camcorder purchase was the backlit camera sensor of the Sony camcorders. This sensor severely reduces graininess in lower light situations making it a must have for me.
Here's how it works. Light sensor pixels are not very reliable at low levels of brightness so the camera turns on the backlight to make sure this doesn't happen. Of course this makes the whole scene uniformly brighter, but the camera uses an algorithm to darken it back down again when the light is on so that you don't notice the difference.
This is a very smart implementation of the technique used in the movies for years to get around the same problems with film cameras. When the crew of a movie films a night scene they don't really film it in the dark. Instead they film it on a well lighted set and darken it in post production avoiding the graininess that comes from low light filming.
Just thought this was interesting.
Here's how it works. Light sensor pixels are not very reliable at low levels of brightness so the camera turns on the backlight to make sure this doesn't happen. Of course this makes the whole scene uniformly brighter, but the camera uses an algorithm to darken it back down again when the light is on so that you don't notice the difference.
This is a very smart implementation of the technique used in the movies for years to get around the same problems with film cameras. When the crew of a movie films a night scene they don't really film it in the dark. Instead they film it on a well lighted set and darken it in post production avoiding the graininess that comes from low light filming.
Just thought this was interesting.
Monday, April 26, 2010
Simplest JQuery ToolTips
Well I think I may have developed the simplest tooltips possible using JQuery. Everything out there seemed too fancy and took too much space, so I just whipped up something super simple. All you need is the amazing JQuery library, this javascript method:
$(document).ready(function(){enableTooltips(verticalOffset, horizontalOffset)}) // Set these values how you like, I used 35, 0
function enableTooltips(topOffset, leftOffset)
{
$('[tooltipText]').bind(
{
mouseover: function() {
if ($('#tooltip').length == 0)
$('body').append('')
var o = $(this).offset()
o.top += topOffset;o.left += leftOffset
$('#tooltip').css(o).html($(this).attr('tooltipText'))
.stop(true).animate({n:0},1000).fadeTo(300,1)
.animate({n:0},5000).fadeTo(500,0)
},
mouseout: function() {
$('#tooltip').stop(true).animate({nothing:0},500).fadeTo(500,0)
}
});
}
And some css like this:
#tooltip {
font:normal 12px Verdanna, Arial, Helvetica, sans-serif;
position: absolute;
z-index: 1000;
border: 1px solid #111;
background-color: #eee;
padding: 2px;
opacity: 0;
filter:alpha(opacity=0);
}
On the items you want tooltips just put a tooltipText property like this:
and you win! JQuery is amazing!
$(document).ready(function(){enableTooltips(verticalOffset, horizontalOffset)}) // Set these values how you like, I used 35, 0
function enableTooltips(topOffset, leftOffset)
{
$('[tooltipText]').bind(
{
mouseover: function() {
if ($('#tooltip').length == 0)
$('body').append('')
var o = $(this).offset()
o.top += topOffset;o.left += leftOffset
$('#tooltip').css(o).html($(this).attr('tooltipText'))
.stop(true).animate({n:0},1000).fadeTo(300,1)
.animate({n:0},5000).fadeTo(500,0)
},
mouseout: function() {
$('#tooltip').stop(true).animate({nothing:0},500).fadeTo(500,0)
}
});
}
And some css like this:
#tooltip {
font:normal 12px Verdanna, Arial, Helvetica, sans-serif;
position: absolute;
z-index: 1000;
border: 1px solid #111;
background-color: #eee;
padding: 2px;
opacity: 0;
filter:alpha(opacity=0);
}
On the items you want tooltips just put a tooltipText property like this:
<input type="submit" src="ButtonHome.gif" tooltiptext="Go to home">
and you win! JQuery is amazing!
Friday, April 23, 2010
The Apple Flash battle is similar to the USB and Floppy transition
Just a short note today as an iPhone user.
It is painful that Apple has booted Flash out of their phone, and as a user it causes me to suffer a bit, but I think change has to hurt. This is just Apple's thing. They like to force innovation to happen, which has made a crucial difference in consumer electronics and software over the years.
Intel invented USB, but could not get it implemented in Windows computers. I was very irritated when Apple tossed their PS2 like serial ports on all their machines but... I think it did have the needed effect of accelerating USB adoption.
They did the same thing with the floppy transition, when they dropped the drives from all their stuff. It was a bit painful for a while but thumb drives and writable CDs came along quickly and solved that.
Apple is irritating people with this, BUT it is absolutely having the effect of making HTML 5 a reality just as it did with USB, and the floppy. Even Microsoft has put very good support in IE 9. I don't think this would have happened nearly as quickly without the iPhone thing, and as a web engineer I appreciate the push.
I must keep my iPhone jailbroken thanks to stupid Apple limitations, but on most things I thank Apple for making me suffer for a bit. Without them we might still be using DOS.
It is painful that Apple has booted Flash out of their phone, and as a user it causes me to suffer a bit, but I think change has to hurt. This is just Apple's thing. They like to force innovation to happen, which has made a crucial difference in consumer electronics and software over the years.
Intel invented USB, but could not get it implemented in Windows computers. I was very irritated when Apple tossed their PS2 like serial ports on all their machines but... I think it did have the needed effect of accelerating USB adoption.
They did the same thing with the floppy transition, when they dropped the drives from all their stuff. It was a bit painful for a while but thumb drives and writable CDs came along quickly and solved that.
Apple is irritating people with this, BUT it is absolutely having the effect of making HTML 5 a reality just as it did with USB, and the floppy. Even Microsoft has put very good support in IE 9. I don't think this would have happened nearly as quickly without the iPhone thing, and as a web engineer I appreciate the push.
I must keep my iPhone jailbroken thanks to stupid Apple limitations, but on most things I thank Apple for making me suffer for a bit. Without them we might still be using DOS.
Friday, January 8, 2010
JSTL is Old Fashioned But Cool
I am not afraid to say that I really like JSTL. It may be old fashioned, but it gets the job done very nicely. Is it just me, or do many of these new frameworks just seem like they don't buy you all that much. Anyway I created this post to shove my favorite JSTL expressions/hacks, toolkits etc. I'll just keep editing it to add more as I think of them/find new ones.
---
Quickly get the current year from JSTL (and jsp)
<jsp:usebean id="now" class="java.util.Date">
<c:set var="year" scope="page" value="${now.year+1900}">
---
I really like the displaytag library. So simple and powerful (especially for internal crud pages).
http://displaytag.sf.net
---
Why does CSS suck so bad? They forget basic things like allowing URLs to break in a table so the table formatting doesn't get thrown out. Here is a snipped to stick hidden breaks in a url so that it will wrap (oh, and still escape xml).... Argh!
${fn:replace(fn:escapeXml(variablename),"/","/
Subscribe to:
Posts (Atom)