Jump to content


Check out our Community Blogs

Register and join over 40,000 other developers!


Recent Status Updates

View All Updates

Photo
- - - - -

Providing web resources only to authenticated users

security login authentication extjs perl web application structure

This topic has been archived. This means that you cannot reply to this topic.
4 replies to this topic

#1 Kaishain

Kaishain

    CC Newcomer

  • Member
  • PipPip
  • 11 posts

Posted 01 February 2014 - 11:47 AM

Firstly, my apologies for such a long post, and apologies again if I'm posting in the wrong area.  It's a fairly complex problem and it's hard to describe exactly what I'm trying to achieve here.

 

I am writing a new web application which consists of a single home page with a login box and then an ExtJS-driven management interface connected to a Perl back end.

 

My site will consist of some generic, publicly available files such as the index.html, the home page stylesheet and the ExtJS library.

 

The management area of my site will then contain other files which I want to make available only to authenticated users.  So, for example, the JS file for instantiating all the ExtJS objects to build my management interface, the JS files containing all of my front end application login, the management interface's stylesheet, etc.

 

I want users to come to my site, view the home page (built using only the publicly available files) and the login form, submit the login form to my Perl login script where I will create them a Perl::CGI session and return a cookie with the session ID, and then be redirected to the management area.  The management area then constructs the ExtJS interface and makes calls to back end Perl scripts to retrieve its dynamic content.

 

The management interface may contain an HTML <link> tag to pull in manager.css, for example, in order to style the management interface.  Once the user is logged in and viewing the management interface, I want their browser to be able to pull in the stylesheet and format the page.  However, I don't want another unauthenticated user to be able to request the stylesheet directly (e.g. by entering http://www.mysite.com/css/manager.css into their browser's address bar).

 

 

So, my questions are:

  • Where do I place my public and protected files?
  • When a client requests one of my resources (e.g. manager.css), how do I direct them through my authentication script before returning the resource?

 

I thought I could structure my files a little like this:

    /cgi-bin
        - login.pl
        - get_resource.pl
    /public_html
        - index.html
        /css
            - home_page.css
    /protected_resources
        /css
            - manager.css
        /script
            - management_interface.js

The files that I want to be available only to authenticated users are outside of the public_html directory so nobody can just browse to them.  In order to access a resource, you have to call /cgi-bin/get_resource.pl?filename=manager.css or similar.  get_resource.pl does an authentication check and then decides if it should return the resource from /protected_resources or not.

 

In my management interface, instead of something like the following:

<head>
    ...
        <link href="/css/manager.css" rel="stylesheet" type="text/css">
    ...
</head>

I'll have something like this:

<head>
    ...
        <link href="/cgi-bin/get_resource.pl?filename=manager.css" rel="stylesheet" type="text/css">
    ...
</head>

Any thoughts, opinions, pointers to web resources, etc. would be greatly appreciated!

 

Cheers



#2 WingedPanther73

WingedPanther73

    A spammer's worst nightmare

  • Moderator
  • 17757 posts

Posted 03 February 2014 - 05:45 AM

General rule of thumb:

If there is a static URL to a file, then it is a public file. Always.

If there is a file with dynamically generated content, then it is a potentially private content. I haven't worked with dynamically generating CSS from a script as a "static" file, but I have to really question why any CSS file would need to be protected content. You're going to lose the caching benefits of having a CSS file if you have to retrieve it dynamically every time.

 

Your idea will work, but I would seriously review whether manager.css and management_interface.js need to be a closely guarded secret. My guess is that if they do, you should move the critical elements out of them and into your generated content.


Programming is a branch of mathematics.
My CodeCall Blog | My Personal Blog

My MineCraft server site: http://banishedwings.enjin.com/


#3 Kaishain

Kaishain

    CC Newcomer

  • Member
  • PipPip
  • 11 posts

Posted 03 February 2014 - 10:34 AM

Thanks for the reply!

 

You're right - I won't be placing any sensitive information in the CSS and JS files, so it's fairly safe to make them accessible to anyone.

 

The main reason for not providing them to the general public is that they might have class names which refer to types of objects in my system, which might let someone guess table names, etc. and aid them in SQL injection attacks and the like.

 

The JS may contain URLs to scripts for retrieving dynamic content; each of those scripts is a potential entry point into my system for a malicious person, so I want to hide them as much as possible.  I guess I could keep all the JS publicly accessible, and initialise some data retrieval URL variables by doing an AJAX and performing an authentication check before returning the URLs.

 

The last potential benefit of returning the script content as I mentioned before was that I could do a permissions/config check against the user and the requested resource to possibly return different versions of the same file.  For example, the page might contain a link to the main ExtJS library file and, depending on the user, I could return either the minified version (to my users) or the debug w/ comments version (to me).



#4 WingedPanther73

WingedPanther73

    A spammer's worst nightmare

  • Moderator
  • 17757 posts

Posted 03 February 2014 - 01:26 PM

Okay, I would have class names based on the meaning of what's displayed, not what's inside. And as far as SQL Injection attacks, obscurity of table names does NOT replace proper security!

 

Any JS that refers to scripts should probably be part of the generated content and embedded directly in returned pages.

 

The whole point of having static files is for caching purposes, to not have to download the file for every request. Split up the universal and specific content accordingly.


Programming is a branch of mathematics.
My CodeCall Blog | My Personal Blog

My MineCraft server site: http://banishedwings.enjin.com/


#5 Kaishain

Kaishain

    CC Newcomer

  • Member
  • PipPip
  • 11 posts

Posted 03 February 2014 - 01:47 PM

I couldn't agree more about security through obscurity not being a safe bet, but it can't hurt to complement other techniques with it.

 

I can take some time, as you suggest, to split up my universal and specific content a bit more.

 

I still like the idea of loading a different version of a script based on who the user is.  Any thoughts on how I might achieve that, if not through some kind of authentication script returning the appropriate version?