what are strategies for shielding off web resources based on business logic

Question

I have a scenario where I'm not really sure my approach is the best one, and I would appreciate feedback / suggestions.

scenario: I have a bunch of flash based (swf) 'modules' which are hosted in my aspnet application. Each flash has it's own directory on the filesystem, which contains assets for the flash. Consider this simplified site structure:

/webapp/index.aspx
/webapp/flash/flash1/flash.swf
/webapp/flash/flash1/someimage.jpg
/webapp/flash/flash1/someclip.mp3
/webapp/flash/flash2/flash.swf
/webapp/flash/flash2/someimage.jpg
/webapp/flash/flash2/someclip.mp3

etcetera

where the naming convention is /webapp/flash/flash[ID]/

I want to implement a security mechanism which checks whether the user should be allowed access* to the files in the subfolder '[ID]' and it's contents.

*insert business logic based on information stored in a SQL database here

I was considering writing a HttpModule which does something like

ProcessRequest(){
    if(Request.RawUrl.Contains("/webapp/flash") && !userHasValidLicenseForModule(1)){
        Redirect("login.aspx");    
    }
}

But there's the drawback that HttpModule only works for file extension which are mapped to aspnet (in IIS6). That means I would have to map all possible extensions to that process (.mp3, .jpg etc) which is something I would rather avoid.

I was also considering to use a HttpHandler instead, but the flash file needs to be able to link to it's resources using relative URLs. (so a proxy-like pattern like /webapp/getprotectedstuff.ashx?file=flash1234/flash.swf is not prefered)

Perhaps it's wiser to store the flash files and assets outside of the web root completely. Perhaps there are other strategies I havent thought of.

Use aspnet security and write a custom membership provider?

Any thoughts?

Answer 1

Have you considered simply validating resource access through an HTTP request to the server after the swf loads?

Where I work we provide online trainings to users through flash but rather than verify the HTTP request itself, we allow the swf's to load first and then make a request to the server to verify that the user should have access to the swf and that they are accessing the swf from within our site and not from another location.

If any step of validation fails (either it fails to find an auth file in the necessary location or the user does not have a valid session or does not have access to the particular training) then they receive an error within flash and none of the important content ever loads.

As another note, if you do decide that you want to strictly limit access to the files so that they can only be loaded by those who should have access, then I would probably suggest using your second option of storing the files in a separate, non-public location and then using a handler script to load the swf.

Answer 2

Thanks :) We're building a training application aswell, by the way (our flash is also at the heart of the training exercise)

I hadn't considered that, actually. It's an interesting approach, it would prevent third parties to host the swf elsewhere (well, they might, but then they couldnt use the resources.)

But people would still be able to guess the URL to the resources and download the them seperately. I have considered URL obfuscation (generating a guid or such) but I don't think that offers sufficient security for my scenario, though, because I'm specifically interested in securing the assets themselves. Some of the images and other stuff are quite confidential.

HttpHandler sounds like a solid solution, but it's inconvenient that I won't be able to use relative URL's to link the files (from within the flash) that way. Especially since we won't be in control of the fla's (they're provided by our client as swf)

Any tips?

Answer 3

Why not go with an ISAPI filter?
Okay, dont answer that - plenty of reasons ;-). But seriously, if you have the dev power for it, you might want to consider that route.

Otherwise, HTTP Module does seem the better route, IF you have a short, closed list of extensions you have to deal with (GIF, JPG, MP3). If its long, or open-ended, I would agree and forgo that.

Another option you might want to look into, if applicable, is role-based NTFS access lists. If this fits, it is probably the easiest and cleanest way to do it.