Maintaining security in an additional servlet

[Flying-w]

I have a GWT application that among many things shows PDFs that are stored on the server side.  I have a security related question, as described below.

When a user logs in through a dialogue on the client side, I make a note of the userid they entered while processing the login on the server side.  This is all done through the normal GWT RPC Infrastructure:

HttpSession session = getThreadLocalRequest().getSession(); 

session.setAttribute("USER", userId);

I have a separate servlet that is responsible for locating and delivering PDF content back to the browser when requested.  When the user clicks a button in the GWT client, I open a new browser window and address the servlet to produce the desired PDF.  A reference to the name of the PDF required is stored in a client side cookie (and transmitted in the HTTP request).

Window.open(GWT.getModuleBaseURL() + "Showpdf", "PDF Viewer", "");

The servlet needs to check whomever is making the request is authorised to view the PDF requested, and checks the user name stored in the HttpSession earlier:

HttpSession session = request.getSession(); 

String user = (String)session.getAttribute("USER");

// Do whatever is required to check the user can access the required PDF

Is this approach is safe from hacking?  Is there a way the user name can be spoofed by a hacker to gain access to a PDF they are not authorised for?  Is there another way of doing this?

Thanks
Simon

[Jeffrey Chimene]

On 1/7/2013 8:43 AM, Flying-w wrote:

I have a GWT application that among many things shows PDFs that are stored on the server side.  I have a security related question, as described below.

When a user logs in through a dialogue on the client side, I make a note of the userid they entered while processing the login on the server side.  This is all done through the normal GWT RPC Infrastructure:

HttpSession session = getThreadLocalRequest().getSession(); 

session.setAttribute("USER", userId);

I have a separate servlet that is responsible for locating and delivering PDF content back to the browser when requested.  When the user clicks a button in the GWT client, I open a new browser window and address the servlet to produce the desired PDF.  A reference to the name of the PDF required is stored in a client side cookie (and transmitted in the HTTP request).

Window.open(GWT.getModuleBaseURL() + "Showpdf", "PDF Viewer", "");

The servlet needs to check whomever is making the request is authorised to view the PDF requested, and checks the user name stored in the HttpSession earlier:

HttpSession session = request.getSession(); 

String user = (String)session.getAttribute("USER");

// Do whatever is required to check the user can access the required PDF

Is this approach is safe from hacking?

Probably not. Rule #1: The client computer is an environment not under your control. It can be hacked. It might /not/ be hacked, but that doesn't mean it /can't/ be hacked. The same goes for whatever Javascript is running on the client. Don't assume that any Javascript comes from a web browser environment, or that it even comes from a PC.

 Is there a way the user name can be spoofed by a hacker to gain access to a PDF they are not authorised for?  Is there another way of doing this?

This is a variant of a common technique for delivering low-value digital content.

The tradeoff is the value of the PDF vs. the strength of the safe in which the PDF is contained. If the PDF is {low value|cheap} and the safe is expensive, that's not a good tradeoff. If the PDF is
{expensive|valuable} than you might want to think of other delivery methods.

Cheers,
jec

[Flying-w]

Thanks for the reply.  The PDF content is highly valuable, so each request must be authenticated and the pdf content must be delivered to the browser securely.

Recommendations for other delivery methods?

Perhaps the ideal solution is to have the PDF content delivered in the response to a GWT RPC method say as a byte array.  The problem is, I've no idea how to get that byte stream rendered in the browser.

Thanks

Simon

[Jeffrey Chimene]

On 01/07/2013 09:23 AM, Flying-w wrote:
> Thanks for the reply. The PDF content is highly valuable, so each
> request must be authenticated and the pdf content must be delivered to
> the browser securely.
>
> Recommendations for other delivery methods?

There is no reason to deliver the content specifically to the browser.
Most folks will use Acrobat to read the PDF, so the browser acts as an
intermediary and increases the attack surface. The content is valuable
(i.e. there is sufficient economic interest to analyze your delivery
method and dupe the server), attacks are possible and economically
beneficial to the attacker.

I'd use email. Deliver the PDF as an attachment. There might be issues
w/ filters.

You might also consider emailing a one-time key as the query string in a
URL, then downloading the PDF in response to that GET. As the key is
associated w/ the user, there is no secondary login required. Also, you
know (i.e. implement in code) that the request can only happen once. It
might also be appropriate to implement a time window in which the URL is
valid.

>
> Perhaps the ideal solution is to have the PDF content delivered in the
> response
> to a GWT RPC method say as a byte array. The problem is, I've no idea
> how to get that byte stream rendered in the browser.

Security by obscurity? No.

Cheers,
jec

[Flying-w]

Once again thanks for the suggestions.  Email won't work here however, as the GWT application is an interactive workflow management tool.  When a user wishes to see a PDF, they need to see it right now rather than wait for a link to be supplied via email.  If browser is the only way forward, how can I do this?

Thanks
Simon

[Andy Stevko]

If the content is highly sensitive, then using adobe's own method of securing it would be the simplest method. Encrypting / Password protecting a pdf file is pretty basic security that would stop the casual hacker.

Your service needs to prevent request record and replay attacks.

Viewing unprotected byte stream within the browser is pretty weak.

An unprotected byte stream response can be monitored and redirected.

For a reasonably vetted model of securing requests and responses, you might look at how AWS SimpleDB, etc authenticates signed timestamped requests and encrypted responses.

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/Q4U23qnnt5kJ.

To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

--
-- A. Stevko

===========

"If everything seems under control, you're just not going fast enough." M. Andretti

[Michael Joyner]

On Mon, Jan 7, 2013 at 2:23 PM, Flying-w <simonj...@googlemail.com> wrote:

Once again thanks for the suggestions.  Email won't work here however, as the GWT application is an interactive workflow management tool.  When a user wishes to see a PDF, they need to see it right now rather than wait for a link to be supplied via email.  If browser is the only way forward, how can I do this?

You still use the LINK method, just return the link to the GWT application which should open a hidden iframe and point the iframe to it.
The servlet, (which you can override your existing get in the GWT rpc servlet btw), when it receives the request and have your servlet  send the PDF with the extra mime-type stuff to force download.