| Input validation (when the term is
used in a security context) consists of performing
syntactic and sometimes semantic checks on data
derived from external (untrusted) sources. Depending
on the criticality of the application and other
factors, the actions performed as a result of input
validation may be one or more of the following:
- replacing syntactic elements with safe ones,
- canceling the use of the affected constructs,
- reporting an error condition,
Input validation can be performed in one of two
modes -- rejecting unsafe characters by enumerating
them, or rejecting unsafe characters by defining
them as the negation of a predefined set of safe
characters.
Sensitive Data
The most trivial method for transferring request
data from the client to the server-side application
is the GET request method, as defined in the CGI
protocol. In this method, the input data is appended
to the request URL and is represented in the form:
URL[?name=value[&name=value[&...]]]
This encoding is clearly unsuitable for transferring
security sensitive information, since the full
URL and the request string normally travel in
clear text over the communication channels and
get logged on all intermediate routers as well
as on the server. When valuable information needs
to be transmitted as part of the client request,
the POST method should be used, with
a suitable encryption mechanism (e.g. over an
SSL connection). From the point of view of the
JSP engine, which method is used is largely irrelevant
-- both methods are handled identically.
In addition, JSP provides the addCookie()
method of the response implicit
object to set a cookie on the client side, and
the getCookie() method
of the request object to retrieve
the contents of a cookie. Cookies are instances
of the javax.servlet.http.Cookie
class.
A security exposure is created when sensitive
information is stored in cookies. First, the whole
content of the cookie is visible to the client,
and second, although browsers normally do not
provide this capability, there is nothing to prevent
a user from responding with an arbitrarily forged
cookie.
In general, none of the information submitted
by the client browser can be assumed to be safe.
Page:
1 2
3 4
NEXT
|
