IBM Support

QRadar: Developing applications and security best practices

Question & Answer


When I create applications in QRadar what are some best practices I can follow as a developer?


Security issues are always a concern and all applications published for IBM Security QRadar include security reviews. This article advises developers on best practices to review when you create an application for QRadar®.

How do I properly handle certificate validation in apps

Due to security concerns, https is preferred over http. The https protocol relies on certificate trusts to ensure validity of the host you are communicating with. Setting the variable verify = False in the certificate causes your app to fail validation as a security risk.

If your app uses only the qpylib to communicate with QRadar
  1. Verify you have the latest version of qpylib, as distributed in SDK version 1.1.0  or greater.
  2. Verify you are on the latest version by observing the lack of:
    verify = false in
  3. Observe the variable:
     APP_CERT_LOCATION = ‘/etc/pki/tls/certs/ca-bundle.crt’ in the
If your app makes https connections to QRadar and DOES NOT use qpylib
  1. The Certificate Authority (CA) for the QRadar certificate for apps when properly configured by an administrator need to be stored in /etc/pki/tls/certs/.
  2. Requests to the QRadar console are made with the FQDN when available and then as a fall-back uses the IP address. Certificates are issued to the FQDN, not the IP address.
If your app is making https connections to services outside of the QRadar deployment. Example, X-Force Exchange
No action is required as the certificate comes from DigiCert, a public Certificate Authority (CA) and is part of most default truststores. Python Requests defaults to true, so if you are not setting verify=False you are already compliant.
If your app makes connection to private services, example a firewall or IDS appliance
  1. The appliance you are connecting to needs to support custom certificates.
  2. If the custom certificate for the appliance is issued by a CA that QRadar trusts, administrators can use the ca-bundle in the same manor you connect to QRadar. This could be the internal CA or a public CA.
  3. If the appliance supports only its own self-signed certs, you could allow the administrator to upload the certificate for that appliance to your app, and trust only that certificate. Apps should always default to the most secure option.
    Note: Trusting specific certificates is poor practice. CAs should always be preferred over individual certificates. If a less-secure configuration must be supported, the administrator needs to explicitly enable it after reading the requisite warnings.

How do you use an Intercepting Proxy to test your app on QRadar

The use of Intercepting Proxies server
The use of Intercepting Proxies is important in testing the security of an app. The reason it is better to use a proxy instead of testing through the UI is that with an Intercepting Proxy you can sidestep some of the safeguards that are put into the UI. For example, if an app needs to ensure only a user can submit a string that starts with “http” a developer might write their JavaScript™ to reject any string that does not match. With an Intercepting Proxy, we can edit the string after it passes through the apps JavaScript, but before it reaches the apps back-end. That means if the app uses the JavaScript to only protect against invalid input, we can completely ignore it with an Intercepting Proxy.

Testing you app by using an Intercepting Proxy server

  1. Users will need to download one of the many tools such as OWASP, Zap, Burp Suite, or others. However, for this example, Burp  Suite community edition is used, however the other software mentioned work the same way.
  2. After your preferred software is installed, you want to go to the options and look for “Proxy Listeners”. This is where your software listens for http requests. Users want to add a listener to with a port that is available. Example interface:
  3. Set up your browser to send your proxy requests. In this example, Firefox is being used. To configure your Firefox browser, click  Preferences > Network Settings > Manual proxy configuration.
  4. Input the proxy interface from step #2. Example: port 8080.
    Important: After this is configured, you need your proxy to access anything for that browser. It is recommend that a second browser such as Chrome® be used for all other requests.
A basic Intercepting Proxy was configured.

How can I use third-party JavaScript™ safely in my QRadar app

Third-party libraries can be used to deliver products faster, but can introduce extra security concerns such as known vulnerabilities. With JavaScript libraries it is important to ensure you are loading them from a trusted source, and that you are getting the file you expect. Loading files from a trusted Content Delivery Network can be a great way to start your project faster with a single line of HTML similar to:

<script src=""></script>
If the file you are loading is modified, your web app and the client's browser have no way to tell. At a minimum, you need to  ensure you use Subresource Integrity (SRI).

Fixing cross-site scripting XSS in apps

Fixing XSS is not as cut and dry as other issues, especially when you use JavaScript to generate parts of your UI. Many popular JavaScript (JS) frameworks have some version of XSS prevention, and it is worth understanding what a JS framework has to offer. The reason XSS is a complicated issue to fix is it can appear in many ways, and the way you fix it is dependent on where the injection occurs. The OWASP outlines 7 rules on XSS prevention. The most important of their rules is rule #0. Deny all. Never use untrusted data ever, except once you have taken the appropriate measures for the location you are in. Most of the XSS issues are when developers dynamically create HTML elements for their page. For example, if you use JavaScript to update the text displayed on part of a page, the use of the  jQuery’s .html() function will not escape any special characters. The use of .text() will escape special characters. For adding text inside of HTML elements, escaping any HTML entities is sufficient. If you need to add data to the tag itself, or inside a , and in QRadar we escape the log source name it is displayed.

What is Directory Traversal?

Directory Traversal or path traversal, is a method for users to access files on a file system they should otherwise not be able to. A common instance where this vulnerability is exposed, is when input is used to determine where a file is located on disk. Example: A forum requests the name of a file to delete. The intended use of this forum is solely to delete files in the /program/logs/ directory. An expected value would be something along the lines of extra.log. The file name given by the user is then be passed to a function such as Python’s os.remove(). This function removes a file given a specified path. Where trouble arrives, is when a user with malicious intent passes in a file name like ../../config/db.json. Rather than removing a .log file, the os.remove() command, not knowing any better, will traverse up the file system two levels - caused by the two ../ - and traverse into the systems config/ directory. The db.json file will then proceed to be deleted. Protection Against Malicious Intent

Types of data to be cautious about putting in apps

 The types of data listed in this section would be best removed from apps.  

  • Usernames.
  • First, or last names.
  • Domain names.
  • Customer or Company names that are not part of the syslog structure.
      For example, Vendor name in LEEF.
  • Hostnames.
  • Public IP.
  • Paths that contain user/domain/host/location/customer names.
      For example, IBM/BA/Anytown/last name
  • Mac address.
  • Passport numbers.
  • Social Security or Insurance numbers.
  • Credit card numbers.
  • Bank account numbers.
  • Physical location information.
  • Biometric information.
  • Email addresses.
  • Telephone numbers.

Acceptable substitution values for payloads, screen captures, or documentation to put in apps

Here is a sample of data that developers can safely use. Use these in place of other common patterns in test data. A single number repeated for each octet in an IP might look like obvious filler data, but unless it falls into the range listed it is not safe to use for documentation.
  • root
  • admin
  • administrator
  • Generic users such as user, user1, user2, user3
  • Generic users such as qradar, qradar1, qradar2
  • Generic users such as testuser1, testuser2, testuser3
IPv4 address internal ranges that comply with Reserved IP addresses
  • -
  • -
Mac addresses reserved for documentation
  • 00-00-5E-00-53-00 through 00-00-5E-00-53-FF for unicast
  • 01-00-5E-90-10-00 through 01-00-5E-90-10-FF for multicast
  • IPv6 Reserved IP addresses
  • 2001:db8:: to 2001:db8:ffff:ffff:ffff:ffff:ffff:ffff reserved for documentation
  • fc00:: - fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff reserved for private networks
  • TLDs
  • .test
  • .example
  • .invalid
  • .localhost
  • Second level domains
This article is a basic guide to security best practices. If you have other questions or concerns, it is best to address them in the QRadar App Development Forums.

[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSBQAC","label":"IBM Security QRadar SIEM"},"ARM Category":[{"code":"a8m0z000000CbaHAAS","label":"QRadar->General Help"}],"ARM Case Number":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Version(s)","Line of Business":{"code":"LOB24","label":"Security Software"}}]

Document Information

Modified date:
19 August 2020