jump to navigation

Web security attacks September 26, 2007

Posted by Coolguy in IT Security.
Tags:
add a comment

Man in the middle attack: Attacker puts up a fake website and entices the user to log on.

Directory harvest: Spammers guess the addresses till they get it right.e-mail servers work at full capacity meanwhile.

Application Security August 16, 2005

Posted by Coolguy in IT Security, Servlets/Jsp.
add a comment
  • Application Developers need to communicate to Deployers how the security is to be set up for the deployed application. This is accomplished declaratively by use of the deployment descriptors mechanism.
  • Servlet containers have mechanisms and infrastructure for meeting these requirements that share some of the following characteristics:
    Authentication: The means by which communicating entities prove to one another that they are acting on behalf of specific identities that are authorized for access.
    Access control for resources: The means by which interactions with resources are limited to collections of users or programs for the purpose of enforcing integrity, confidentiality, or availability constraints.
    Data Integrity: The means used to prove that information has not been modified by a third party while in transit.
    Confidentiality or Data Privacy: The means used to ensure that information is made available only to users who are authorized to access it.

Declarative Security:

  • Declarative security refers to the means of expressing an application’s security structure, including roles, access control, and authentication requirements in a form external to the application.
  • The deployment descriptor is the primary vehicle for declarative security in web applications.
  • The Deployer maps the application’s logical security requirements to a
    representation of the security policy that is specific to the runtime environment.
  • At runtime, the servlet container uses the security policy representation to enforce authentication and authorization.
  • The security model applies to the static content part of the web application and to servlets and filters within the application that are requested by the client.
  • The security model does not apply when a servlet uses the RequestDispatcher to invoke a static resource or servlet using a forward or an include

Programmatic Security

  • Programmatic security is used by security aware applications when declarative security alone is not sufficient to express the security model of the application.
  • Programmatic security consists of the following methods of the
    HttpServletRequest interface:
    • getRemoteUser
    • isUserInRole
    • getUserPrincipal
  • The getRemoteUser method returns the user name the client used for
    authentication.
  • The isUserInRole method determines if a remote user is in a
    specified security role.
  • The getUserPrincipal method determines the principal
    name of the current user and returns a java.security.Principal object.
  • If no user has been authenticated, the getRemoteUser method returns null , the isUserInRole method always returns false , and the getUserPrincipal method returns null
  • The isUserInRole method expects a String user role-name parameter.
  • A security-role-ref element should be declared in the deployment descriptor with a role-name sub-element containing the rolename to be passed to the method.
  • For example, to map the security role reference “FOO” to the security role with role-name “manager” the syntax would be:<security-role-ref>

    <role-name>FOO</role-name>

    <role-link>manager</role-link>

    </security-role-ref>

  • In this case if the servlet called by a user belonging to the “manager” security role made the API call isUserInRole(“FOO”)the result would be true.

Roles

  • A security role is a logical grouping of users defined by the Application Developer or Assembler.
  • When the application is deployed, roles are mapped by a Deployer to
    principals or groups in the runtime environment.

Authentication

  • A web client can authenticate a user to a web server using one of the following mechanisms:
    • HTTP Basic Authentication
    • HTTP Digest Authentication
    • HTTPS Client Authentication
    • Form Based Authentication

HTTP Basic Authentication

  • HTTP Basic Authentication, which is based on a username and password, is the authentication mechanism defined in the HTTP/1.0 specification.
  • A web server requests a web client to authenticate the user. As part of the request, the web server passes the realm (a string) in which the user is to be authenticated.
  • The web client obtains the username and the password from the user and transmits them to the web server. The web server then authenticates the user in the specified realm.
  • Basic Authentication is not a secure authentication protocol. User passwords are sent in simple base64 encoding, and the target server is not authenticated.
  • Additional protection can alleviate some of these concerns: a secure transport mechanism (HTTPS), or security at the network level (such as the IPSEC protocol or VPN strategies) is applied in some deployment scenarios.

HTTP Digest Authentication

  • Like HTTP Basic Authentication, HTTP Digest Authentication authenticates a user based on a username and a password.
  • However the authentication is performed by transmitting the password in an encrypted form which is much more secure than the simple base64 encoding used by Basic Authentication,
  • e.g. HTTPS Client Authentication.

Form Based Authentication

  • The web application deployment descriptor contains entries for a login form and error page.
  • The login form must contain fields for entering a username and a
    password. These fields must be named j_username and j_password , respectively.
  • When a user attempts to access a protected web resource, the container checks the user’s authentication. If the user is authenticated and possesses authority to access the resource, the requested web resource is activated and a reference to it is returned.
  • If the user is not authenticated, all of the following steps occur:
    1. The login form associated with the security constraint is sent to the client and the URL path triggering the authentication is stored by the container.
    2. The user is asked to fill out the form, including the username and password fields.
    3. The client posts the form back to the server.
    4. The container attempts to authenticate the user using the information from the form.
    5. If authentication fails, the error page is returned using either a forward or a re-direct, and the status code of the response is set to 200.
    6. If authentication succeeds, the authenticated user’s principal is checked to see if it is in an authorized role for accessing the resource.
    7. If the user is authorized, the client is redirected to the resource using the stored URL path.
  • The error page sent to a user that is not authenticated contains information about the failure.
  • Form Based Authentication has the same lack of security as Basic
    Authentication since the user password is transmitted as plain text and the target server is not authenticated.
  • Form based login should be used only when sessions are being maintained by cookies or by SSL session information.
  • In order for the authentication to proceed appropriately, the action of the login form must always be j_security_check
  • Here is an example showing how the form should be coded into the HTML page:

    <form method=”POST ” action==”j_security_check “>

    <input type=”text ” name==”j_username “>

    <input type=”password ” name==”j_password “>

    </form>

HTTPS Client Authentication

  • End user authentication using HTTPS (HTTP over SSL) is a strong authentication mechanism.
  • This mechanism requires the user to possess a Public Key Certificate
    (PKC).
  • Currently, PKCs are useful in e-commerce applications and also for a single-signon from within the browser.

Server Tracking of Authentication Information

  • A servlet container is required to track authentication information at the container level (rather than at the web application level). This allows users
    authenticated for one web application to access other resources managed by the container permitted to the same security identity.
  • A security identity, or principal, must always be provided for use in a call to an enterprise bean.
  • The default mode in calls to enterprise beans from web applications
    is for the security identity of a web user to be propagated to the EJB container.
  • Web containers are required to support access to web resources by clients that have not authenticated themselves to the container.
  • Security constraints are a declarative way of defining the protection of web content.
  • A security constraint associates authorization and or user data constraints with HTTP operations on web resources.
  • A security constraint, which is represented by security-constraint in deployment descriptor, consists of the following elements:
    • web resource collection (resource-collection in deployment descriptor)
    • authorization constraint (constraint in deployment descriptor)
    • user data constraint (data-constraint in deployment descriptor)

Web resource collection

  • The HTTP operations and web resources to which a security constraint
    applies are identified by one or more web resource collections.
  • A web resource collection consists of the following elements:
    URL patterns (url-pattern in deployment descriptor)
    HTTP methods (http-method in deployment descriptor)

Authorization constraint

  • An authorization constraint establishes a requirement for authentication and names the authorization roles permitted to perform the constrained requests.
  • A user must be a member of at least one of the named roles to be permitted to perform the constrained requests.
  • The special role name “*” is a shorthand for all role names defined in the deployment descriptor.
  • An authorization constraint consists of the following element:
    • role name (role-name in deployment descriptor)

User data constraint

  • A user data constraint establishes a requirement that the constrained requests be received over a protected transport layer connection.
  • The strength of the required protection is defined by the value of the transport guarantee.
  • A transport guarantee of INTEGRAL is used to establish a requirement for content integrity
  • Transport guarantee of CONFIDENTIAL is used to establish a requirement for confidentiality.
  • The transport guarantee of “NONE” indicates that the container must accept the constrained requests when received on any connection
    including an unprotected one.
  • A user data constraint consists of the following element:
    • transport guarantee (transport-guarantee in deployment descriptor)
  • If no authorization constraint applies to a request, the container must accept the request without requiring user authentication.
  • If no user data constraint applies to a request, the container must accept the request when received over any connection including an unprotected one.
  • Authorization constraint that names no roles shall combine with any other constraints to override their affects and cause access to be precluded.
  • The following example illustrates the combination of constraints and their
    translation into a table of applicable constraints.
  • Suppose that a deployment descriptor contained the following security constraints.

<security-constraint>

<web-resource-collection>

<web-resource-name>restricted methods</web-resource-name>

<url-pattern>/*</url-pattern>

<url-pattern>/acme/wholesale/*</url-pattern>

<url-pattern>/acme/retail/*</url-pattern>

<http-method>DELETE</http-method>

<http-method>PUT</http-method>

</web-resource-collection>

<auth-constraint/>

</security-constraint>

<security-constraint>

<web-resource-collection>

<web-resource-name>wholesale</web-resource-name>

<url-pattern>/acme/wholesale/*</url-pattern>

<http-method>GET</http-method>

<http-method>PUT</http-method>

</web-resource-collection>

<auth-constraint>

<role-name>SALESCLERK</role-name>.

</auth-constraint>

</security-constraint>

<security-constraint>

<web-resource-collection>

<web-resource-name>wholesale</web-resource-name>

<url-pattern>/acme/wholesale/*</url-pattern>

<http-method>GET</http-method>

<http-method>POST</http-method>

</web-resource-collection>

<auth-constraint>

<role-name>CONTRACTOR</role-name>

</auth-constraint>

<user-data-constraint>

<transport-guarantee>CONFIDENTIAL</transport-guarantee>

</user-data-constraint>

</security-constraint>

<security-constraint>

<web-resource-collection>

<web-resource-name>retail</web-resource-name>

<url-pattern>/acme/retail/*</url-pattern>

<http-method>GET</http-method>

<http-method>POST</http-method>

</web-resource-collection>

<auth-constraint>

<role-name>CONTRACTOR</role-name>

<role-name>HOMEOWNER</role-name>

</auth-constraint>

</security-constraint>

  • The translation of this hypothetical deployment descriptor would yield the
    constraints defined in Table

url-pattern

http-method

permitted roles

supported connection types

/* DELETE No access not constrained

/* PUT No access not constrained

/acme/wholesale/*

DELETE No access not constrained
acme/wholesale/*

GET SALESCLERK
CONTRACTOR
not constrained
acme/wholesale/* PUT No access not constrained
acme/wholesale/* POST CONTRACTOR CONFIDENTIAL
/acme/retail/*

DELETE

No access

not constrained
/acme/retail/*

PUT

No access

not constrained
/acme/retail/*

GET

CONTRACTOR
HOMEOWNER
not constrained

/acme/retail/*

POST

CONTRACTOR
HOMEOWNER
not constrained

Processing Requests

  • When a Servlet container receives a request, it shall use a algorithm to select the constraints (if any) defined on the url-pattern that is the best match to the request URI.
  • If no constraints are selected, the container shall accept the request.
  • Otherwise the container shall determine if the HTTP method of the request is constrained at the selected pattern.
  • If it is not, the request shall be accepted.
  • Otherwise, the request must satisfy the constraints that apply to the http-
    method
    at the url-pattern
  • The characteristics of the connection on which the request was received must satisfy at least one of the supported connection types defined by the con-straints. If this rule is not satisfied, the container shall reject the request and re-direct it to the HTTPS port.
  • The authentication characteristics of the request must satisfy any authentication and role requirements defined by the constraints.
  • If this rule is not satisfied because access has been precluded (by an authorization constraint naming no roles), the request shall be rejected as forbidden and a 403 (SC_FORBIDDEN ) status code shall be returned to the user.
  • If access is restricted to permitted roles and the request has not been authenticated, the request shall be rejected as unauthorized and a 401
    (SC_UNAUTHORIZED ) status code shall be returned to cause authentication.
  • If access is restricted to permitted roles and the authentication identity of
    the request is not a member of any of these roles, the request shall be re-jected as forbidden and a 403 (SC_FORBIDDEN ) status code shall be returned to the user.
  • By default, authentication is not needed to access resources. Authentication is needed for requests for a web resource collection only when specified by the deployment descriptor.
  • Containers may create HTTP Session objects to track login state. If a
    developer creates a session while a user is not authenticated, and the container then authenticates the user, the session visible to developer code after login must be the same session object that was created prior to login occurring so that there is no loss of session information.

Building secure webservices August 11, 2005

Posted by Coolguy in IT Security, Web Services.
Tags:
add a comment

Broadly speaking there are might have five security requirements in webservices:

  1. Confidentiality : Ensuring that information is accessible only to those authorized to have access
  2. Authorization : The authorization process is used to decide if person, program or device X is allowed to have access to data, functionality or service Y
  3. Data integrity :Ensures that data is unchanged from its source and has not been accidentally or maliciously modified, altered, or destroyed
  4. Message origin authentication
  5. Non-repudiation : Nonrepudiation means to ensure that a transferred message has been sent and received by the parties claiming to have sent and received the message. Nonrepudiation is a way to guarantee that the sender of a message cannot later deny having sent the message and that the recipient cannot deny having received the message

First 3 of these can be safely managed by using we transport layer security mechanisms such as SSL. Using SSL the channel over which two parties communicate can be kept confidential – data is encrypted by the sender and decrypted by the recipient. With server-side SSL the client obtains a copy of the Web server’s certificate, allowing it to authenticate the server and establish an encrypted channel. Client-side SSL enables two-way authentication, enabling clients to authenticate service providers and service providers to authenticate clients. However, it requires that digital certificates be distributed to all users, which results in significant administrative problems.It would still work if we have a service used by clients whom we know. Obviously more secure than just server-side SSL and works well in reassuring clients of security of our services. These sould be pretty straight forward to implement.

Typical steps are likely to be:

  1. Approach any CA to issue digital certificate for your company.
  2. Use OpenSSL and Mod SSL to secure webservers.
  3. Give certificates to all clients who will access the system and would work straight away.

But SSL does not address the need for accountability (if its needed). It is difficult to even prove that an SSL session existed once it has been closed. Keyed-hashing such as HMAC, using a secret key shared in an authenticated way, is sufficient for message origin authentication, but not sufficient for non-repudiation. Non-repudiation requires a digital signature algorithm such as RSA or DSA. In effect you need to go for SOAP Layer security if:

  1. If you use of variety of transport protocols such as HTTP and SMTP, which could make transport layer security a bit flaky. Even though SOAP can use any transport layer, most widely used is HTTP.
  2. If there are intermediaries which handle the message before even reaching to your servers, then relying on SSL would fail.

So you might as well do with transport layer security as long as we dont need accountablility which might vary from application to application. If you do need accountability we could use employ XML signatures.

SSL fails to protect Web services from more traditional forms of attacks. For example, a hacker could stage a buffer overflow attack by sending through parameters that are longer than the Web service expects. Validating the content of messages before routing to the Web service and keeping account of Web service usage can counteract this type of attack. SSL does not identify harmful message content or provide records of usage that would enable these attacks to be detected. To ensure that no malicious data is sent to a Web Service that would cause that service to fail, the content of a message can be verified against an XML Schema. This ensures that the structure of the message is correct and may also involve checking that the values of parameters meet those outlined in the XML Schema.

Implementation details specific to Java:

JSSE which is now a part of JDK could be used to establish a connection with a SSL server. javax.net.ssl.*,javax.security.cert.X509Certificate and java.security.KeyStore packages will help in establishing a connection with a secure server. You give a keyfile,password and url to the clients who will then use this info and above classes to write clients which talk to secure server. Typically a client would:

  • Load the certificate
  • Check its still valid
  • Create a SSLSocket to the URL provided on the port provided.(443 on live and 444 for testing ?)
  • Write the SOAP message to the socket
  • Wait for server to acknowledge the message
  • Close and go away

Security tid-bits April 9, 2005

Posted by Coolguy in IT Security.
add a comment

Security :
Man in the middle attack:Attacker puts up a fake website and entices the user to log on.

Directory harvest:Spammers guess the addresses till they get it right.e-mail servers work at full capacity meanwhile.

IDS vs. IPS: Is one strategy ‘better?’ February 23, 2005

Posted by Coolguy in IT Security.
Tags:
add a comment

IDS vs. IPS: Is one strategy ‘better?’

Protecting Passwords February 23, 2005

Posted by Coolguy in IT Security.
Tags:
add a comment

Protecting Passwords

Password Encryption: Rationale and Java Example February 23, 2005

Posted by Coolguy in IT Security.
Tags:
add a comment

Password Encryption: Rationale and Java Example

Quantum Cryptography November 17, 2004

Posted by Coolguy in IT Security.
add a comment

Watch out. Looks like this is out of labs by 2006