A Cross-Site Request Forgery (CSRF) attack exploits the
trust that a web site has for the user, to transmit commands that
are unauthorized and unintended by the user. The attack is set up
by including a link or a script in a web page, or a URL in an e-mail
message, to access another site to which the user has already been authenticated.
For example, you may be logged in to Administration Console while
simultaneously browsing another website. One of the web pages may
include an HTML image tag with a src attribute
that targets a server-side script on the victim website. By leveraging
the cookie-based session-authentication mechanism provided by web
browsers, the attacking website can send malicious requests to this
victim server-side script, masquerading as the legitimate user.
For more examples, see https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)#Examples.
The following characteristics are common to CSRF: Involve
sites that rely on a user's identity.
Exploit the site's trust in that identity.
Trick the user's browser into sending HTTP requests to a
target site.
Involve HTTP requests that have side effects.
LiveCycle uses the Referer Filter feature to block CSRF attacks.
The following terms are used in this section to describe the Referer
Filtering mechanism:
Allowed Referer: A Referer is the address of the
source page that sends a request to the server. For JSP pages or
forms, the Referer is usually the previous page in the browsing
history. Referers for images are usually the pages on which the
images are displayed. You can identify the Referers that are allowed access
to your server resources by adding them to the Allowed Referer list.
Allowed Referer Exceptions: You may want to restrict
the scope of access for a particular Referer in your Allowed Referer
list. To enforce this restriction you can add individual paths of
that Referer to the Allowed Referer Exceptions list. Requests originating
from paths in the Allowed Referer Exceptions list are prevented
from invoking any resource on the LiveCycle server. You can define Allowed
Referer Exceptions for a specific application and also use a global
list of exceptions that apply to all applications.
Allowed URIs: This is a list of resources that are
to be served without checking the Referer Header. Resources, for
example, help pages, that do not result in state changes on the
server, can be added to this list. The resources in the Allowed
URIs list are never blocked by the Referer Filter irrespective of
who the Referer is.
Null Referer: A server request that is not associated
with or does not originate from a parent web page is considered
to be a request from a Null Referer. For example, when you open
a new browser window, type an address, and press enter, the Referer
sent to the server is null. A desktop application (.NET or SWING)
making an HTTP request to a web server, also sends a Null Referer
to the server.
|
|
|