Now here’s something I wouldn’t expect to see outside of a test environment. Anyone that’s worked with web acceleration or web caching knows how easy it is to allow applications to expose the wrong data to the wrong client if you’re not setting your policies properly.

A woman logged onto facebook on her AT&T cellular phone and got ‘GASP’, someone else’s facebook account!!!

Never having worked with proxying on the ISP level, I wonder how much caching and acceleration AT&T or the other big mobile carriers are doing for their customers. I can imagine they may be dabbling with it a bit as cell phones have limited data capabilities too.

The danger here is if AT&T was web acceleration/caching on some of the more well known and widely used sites out there, such as facebook as requests entered/exited their network. Not knowing the ins and outs of the application of which you’re caching is one of the worst things you can do in web acceleration, and no doubt can VERY EASILY lead to something like this occuring.

I’ve actually managed to do something like this in a test environment before and it was quite interesting. Application X was being cached by an F5 Web Accelerator and no matter what I did, every time the RamCache was enabled and clients logged in, they would not necessarily get their intended session, sometimes (most of the time) they would get hooked into someone else’s session and was able to do, think and act as if they were some other user-possibly a privileged user even. It turns out that a simple iRule fixed the problem – disable the RamCache only for the specific file which acted much like a ‘controller’ for the application in general, not necessarily needing to be cached really anyway.

Here’s the iRule I used, very simple:

when HTTP_REQUEST {
if { [HTTP::uri] contains ".extension" } { CACHE::disable }
}

Source: Fox News, Personal experience

Share on Facebook