CODEWITHSUNDEEP
javacookiessecurityaccess-control
SHH
SHH

Reputation: 502

How can I block a particular client from a web application?

There is a Java application requesting a page and I wish to block it.

One way I thought to do this was to use sessions or cookies, but I wasn't sure if the Java URL method could handle them or not.

Is there another way besides using sessions or cookies that I could distinguish requests from this Java application and block it? I know it has a unique Java user-agent header but I wish to be more accurate.

Upvotes: 0

Views: 1041

Answers (2)

Stephen C
Stephen C

Reputation: 719679

The answer to the headline Question is that the URL.openXxx methods do not understand cookies.

(If your server is configured to accept session tokens in the request URL itself, the URL.openXxx methods won't get in the way. However, that approach is insecure.)

Then we come to the body of your Question.

... is there another way besides using sessions or cookies that i could distinguish requests from this java app and block it?

At this point, I assume that you are talking about blocking requests on the server side. And I should point out that what the "bad guy" client uses to send the request is now immaterial. (It could use URL or Apache HTTPComponents or it could implement the HTTP protocol stack in assembly code!)

So the real question is what options you have for blocking unwanted requests. And the answer is:

  • You could block based on the request URL itself, though this is probably counter-productive.
  • You could block based on the presence of session (or other) cookies in the request headers. This is the normal way of doing access control, and assuming that you issue and handle the cookies securely, this is hard to defeat.
  • You could require that session tokens are passed in the request URL, but this has fundamental security issues.
  • You could rely on other "informative" headers ... such as the user-agent header, but this is trivial to defeat.
  • You could block based on the request source IP address, but all the bad guy needs to do is to send the requests from a different IP address.
  • You could limit access by using HTTP over SSL/TLS with client-side certificates, but this means that you have to manage certificates for all legitimate client hosts, which is problematic in most environments.

In summary, cookies are the best solution, so the "good guy" client application needs to use libraries that are capable of doing cookie management and setting cookies in requests.

Upvotes: 2

Matt
Matt

Reputation: 11815

URL is only a representation of the sever you're trying to talk to. It has some convenience methods for opening connections and so forth, but that's it.

Sessions are a handled in one of two ways: cookies or url rewriting. These have little or nothing to do with the URL class (other than the session id being placed in the URL in the latter).

The user agent seems to be your best bet, short of enabling some some of password (http basic, digest, etc...) or ssl certificate verification. that being said, user agents are entire at the client side's discretion and can easily be changed by the client to impersonate other browsers.

Upvotes: 2

Related Questions