Explore topic-wise InterviewSolutions in .

SQL injection attacks are attempts by malicious users to access or alter DATABASE information available only to the WEB application. XPath injection attacks are attempts to access or alter XML data.

ATTACKERS alter user-submitted requests to do the following:

• GAIN more knowledge about the structure of the database or XML data
• OBTAIN sensitive data such as user names and passwords
• Corrupt or delete data in the database.

SQL injection attacks are attempts by malicious users to access or alter database information available only to the web application. XPath injection attacks are attempts to access or alter XML data.

Attackers alter user-submitted requests to do the following:

An injection FILTER blocks requests that are considered likely to perform injection attacks. The filter protects against injection attacks as follows:

• ANALYZES INCOMING requests and validates that the input data is well-formed
• Ensures that the request is not attempting to alter SQL STATEMENTS or XML data embedded in the application
• This protection is achieved by applying a number of regular expressions against different parts of the HTTP request. Any match indicates that the request might be malicious and causes the firewall to log, reject, or redirect the request.

An injection filter blocks requests that are considered likely to perform injection attacks. The filter protects against injection attacks as follows:

A back end server or the requesting client might be expecting some special characters such as the British Pound symbol and letters with umlauts, accents, or other special marks; however, these special characters are not preserved when they pass through the DataPower appliance.

Take the following steps to resolve the problem:

• Set include charset in response-type to on:
• For the Multi-Protocol Gateway service or the Web Service PROXY service:
• Use the Objects navigator to open the service configuration screen.
• Choose the Proxy Settings tab and set include charset in response-type to on.
• For the XML FIREWALL service:
• Use the Objects navigator to open the XML Firewall service configuration screen.
• Choose the HTTP Options tab and set HTTP charset in response-type to on.
• Edit the XML Manager that you are using in your service so that the XML Manager contains a minimum output escaping rule:
• Add a new Compile Options Policy or select an existing ONE by clicking ....
• Add a Minimum Output Escaping Rule.
• Add a MATCHING rule so that all requests coming in on that URI (it can be * ) are minimally ESCAPED.
• Use a style sheet in the transform action in your processing rule. Include the following line in the style sheet to specify output encoding:

<xsl:output encoding="UTF-8" version="1.0" method="xml"/>

• Make sure that you transform the incoming request with your style sheet, even minimally; otherwise, the settings in step 2 are not used. If you do not want to transform the request, insert the following line in between the xsl:template element tags:

<a>
<xsl:copy-of select="."/>
</a>

Optional: If your response still escapes the special characters, clear the stylesheet cache. Clearing the style sheet cache ensures that the DataPower appliance uses the current settings.

A back end server or the requesting client might be expecting some special characters such as the British Pound symbol and letters with umlauts, accents, or other special marks; however, these special characters are not preserved when they pass through the DataPower appliance.

Take the following steps to resolve the problem:

<xsl:output encoding="UTF-8" version="1.0" method="xml"/>

<a>
<xsl:copy-of select="."/>
</a>

Optional: If your response still escapes the special characters, clear the stylesheet cache. Clearing the style sheet cache ensures that the DataPower appliance uses the current settings.

To verify that your CUSTOM injection patterns FILE is working correctly, check the default log for any messages that report parsing failure. A parsing failure COULD occur for any of the following reasons:

• The file contains XML that is not well-formed.
• The file contains XML that does not conform to the XML schema.
• The file was deleted after the configuration was saved.
• The file does not EXIST or is in the wrong location.

To verify that your custom injection patterns file is working correctly, check the default log for any messages that report parsing failure. A parsing failure could occur for any of the following reasons:

File system structure in DataPower is one of the main component that we need to look out for while working on day to day activities. Below image shows the directory structure in DataPower.

Following are details of all the Folders present and their description.

audit: This directory contains the audit LOGS. Each appliance contains only one audit: directory. This directory cannot be the destination of a copy.This directory is available from the CLI in only the default domain.

cert: This encrypted directory contains private key and certificate files that services use in the domain. You can add, delete, and list files in this directory but you cannot view or modify these files. Each application domain contains one cert: directory. This directory is not shared across domains.

chkpoints: This directory contains the configuration checkpoint files for the appliance. Each application domain contains one chkpoints: directory. This directory is not shared across domains. During an UPGRADE, the operation deletes the contents of this directory.

config: This directory contains the configuration files for the appliance. Each application domain contains one config: directory. This directory is not shared across domains.

dpcert: This encrypted directory contains files that the appliance itself uses. This directory is available from the CLI in only the default domain.

export: This directory contains the export packages. Each application domain contains one export: directory. This directory is not shared across domains.

image: This directory contains the firmware images (primary and secondary) for the appliance. This directory is where firmware images are stored typically during an upload or fetch operation. Each appliance contains only one image: directory. This directory is available in only the default domain. During an upgrade, the operation deletes the contents of this directory.

internalconfig: This hidden directory contains configuration-like artifacts for the appliance. This directory is where predefined deployment artifacts like pattern exemplars are stored. You cannot access this directory with any interface.

isamcert: This directory contains shared certificate and key files. When a shared file is changed, all reverse proxies must be restarted.

isamconfig: This directory contains the following files.

The Access Manager Reverse Proxy configuration files. There is one configuration file per reverse proxy. The files are NAMED in the isamconfig:///webseald-name.conf format.

The Access Manager Reverse Proxy routing files. There is one routing file per reverse proxy. The files are named in the isamconfig:///routing-name format.

isamwebroot: This directory contains files for each Access Manager Reverse Proxy. When a file in this directory is changed, only the reverse proxy that is modified must be restarted.

local: This directory contains miscellaneous files that are used by the services within the domain, such as XSL, XSD, and WSDL files. Each application domain contains one local: directory. This directory can be made visible to other domains. When viewed from other domains, the directory name changes from local: to the name of the application domain.

logstore: This directory contains log files that are stored for FUTURE reference. Typically, the logging targets use the logtemp: directory for active logs. You can move log files to the logstore: directory. Each application domain contains one logstore: directory. This directory is not shared across domains.

logtemp: This directory is the default location of log files, such as the appliance-wide default log. This directory can hold 13 MB. This directory cannot be the destination of a copy. Each application domain contains one logtemp: directory. This directory is not shared across domains.

policyframework: This directory contains unattached policies that are submitted to the appliance through the REST management interface. Do not modify files in this directory. To modify an unattached policy, DELETE and POST the policy through the REST management interface. This process ensures that the policy is recompiled. This directory is not shared across domains.

pubcert: This encrypted directory contains the security certificates that are used commonly by web browsers. These certificates are used to establish security credentials. Each appliance contains only one pubcert: directory. This directory is not shared across domains. However, you must be in default domain to upload or fetch files.

sharedcert: This encrypted directory contains security certificates that are shared. Each appliance contains only one sharedcert: directory. This directory is not shared across domains. However, you must be in default domain to upload or fetch files.

store: This directory contains example stylesheets, default stylesheets, and schemas that the appliance itself uses. Do not modify files in this directory. Each appliance contains only one store: directory. Although this directory is visible to all domains, you can change the contents of this directory from only the default domain.

tasktemplates: This directory contains the XSL files that define the display of specialized GUI screens. Each appliance contains only one tasktemplates: directory. This directory is available in only the default domain.

temporary: This directory is used as temporary disk space by processing RULES. Each application domain contains one temporary: directory. This directory is not shared across domains. During an upgrade, the operation deletes the contents of this directory.

File system structure in DataPower is one of the main component that we need to look out for while working on day to day activities. Below image shows the directory structure in DataPower.

Following are details of all the Folders present and their description.

audit: This directory contains the audit logs. Each appliance contains only one audit: directory. This directory cannot be the destination of a copy.This directory is available from the CLI in only the default domain.

cert: This encrypted directory contains private key and certificate files that services use in the domain. You can add, delete, and list files in this directory but you cannot view or modify these files. Each application domain contains one cert: directory. This directory is not shared across domains.

chkpoints: This directory contains the configuration checkpoint files for the appliance. Each application domain contains one chkpoints: directory. This directory is not shared across domains. During an upgrade, the operation deletes the contents of this directory.

config: This directory contains the configuration files for the appliance. Each application domain contains one config: directory. This directory is not shared across domains.

dpcert: This encrypted directory contains files that the appliance itself uses. This directory is available from the CLI in only the default domain.

export: This directory contains the export packages. Each application domain contains one export: directory. This directory is not shared across domains.

image: This directory contains the firmware images (primary and secondary) for the appliance. This directory is where firmware images are stored typically during an upload or fetch operation. Each appliance contains only one image: directory. This directory is available in only the default domain. During an upgrade, the operation deletes the contents of this directory.

internalconfig: This hidden directory contains configuration-like artifacts for the appliance. This directory is where predefined deployment artifacts like pattern exemplars are stored. You cannot access this directory with any interface.

isamcert: This directory contains shared certificate and key files. When a shared file is changed, all reverse proxies must be restarted.

isamconfig: This directory contains the following files.

The Access Manager Reverse Proxy configuration files. There is one configuration file per reverse proxy. The files are named in the isamconfig:///webseald-name.conf format.

The Access Manager Reverse Proxy routing files. There is one routing file per reverse proxy. The files are named in the isamconfig:///routing-name format.

isamwebroot: This directory contains files for each Access Manager Reverse Proxy. When a file in this directory is changed, only the reverse proxy that is modified must be restarted.

local: This directory contains miscellaneous files that are used by the services within the domain, such as XSL, XSD, and WSDL files. Each application domain contains one local: directory. This directory can be made visible to other domains. When viewed from other domains, the directory name changes from local: to the name of the application domain.

logstore: This directory contains log files that are stored for future reference. Typically, the logging targets use the logtemp: directory for active logs. You can move log files to the logstore: directory. Each application domain contains one logstore: directory. This directory is not shared across domains.

logtemp: This directory is the default location of log files, such as the appliance-wide default log. This directory can hold 13 MB. This directory cannot be the destination of a copy. Each application domain contains one logtemp: directory. This directory is not shared across domains.

policyframework: This directory contains unattached policies that are submitted to the appliance through the REST management interface. Do not modify files in this directory. To modify an unattached policy, DELETE and POST the policy through the REST management interface. This process ensures that the policy is recompiled. This directory is not shared across domains.

pubcert: This encrypted directory contains the security certificates that are used commonly by web browsers. These certificates are used to establish security credentials. Each appliance contains only one pubcert: directory. This directory is not shared across domains. However, you must be in default domain to upload or fetch files.

sharedcert: This encrypted directory contains security certificates that are shared. Each appliance contains only one sharedcert: directory. This directory is not shared across domains. However, you must be in default domain to upload or fetch files.

store: This directory contains example stylesheets, default stylesheets, and schemas that the appliance itself uses. Do not modify files in this directory. Each appliance contains only one store: directory. Although this directory is visible to all domains, you can change the contents of this directory from only the default domain.

tasktemplates: This directory contains the XSL files that define the display of specialized GUI screens. Each appliance contains only one tasktemplates: directory. This directory is available in only the default domain.

temporary: This directory is used as temporary disk space by processing rules. Each application domain contains one temporary: directory. This directory is not shared across domains. During an upgrade, the operation deletes the contents of this directory.

SSL are digital signed certificates. USER for meesage/communication integrity and confidentiality. Generally encrypt at Sender SIDE and decrypt at RECEIVER side.

SSL are digital signed certificates. user for meesage/communication integrity and confidentiality. Generally encrypt at Sender side and decrypt at receiver side.

Different types Data power appliances :-

XML Accelerator XA35: 

• Accelerates XML processing and transformation.
• Increases throughput and reduces latency.
• Lowers development costs.

XML SECURITY Gateway XS40:

• Help secure SOA with XML threat protection andaccess control
• Combines Web SERVICES security, routing and management functions Drop-in, centralized policy enforcement.
• Easily integrates with existing infrastructure and processes.

Integration Appliance XI50:-

• TRANSFORMS messages (Binary to XML, Binary toBinary, XML to Binary)
• Bridges multiple protocols (e.g. MQ, HTTP,JMS)
• Routes messages based on content and policy.
• Integrates message-level security and policy Functions.

Different types Data power appliances :-

XML Accelerator XA35: 

XML Security Gateway XS40:

Integration Appliance XI50:-

TRUE: logtemp, DEFAULT LOCATION of LOG FILES, such as the system-wide default log.

True: logtemp, default location of log files, such as the system-wide default log.

we need logtarget to capture messages that are POSTED by the VARIOUS objects and SERVICES that are running on the appliance. In order to GET a specific event or/and object log information, we UTILIZE logtargets.

we need logtarget to capture messages that are posted by the various objects and services that are running on the appliance. In order to get a specific event or/and object log information, we utilize logtargets.