QRadar: Developing applications and security best practices

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.

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 live_qpylib.py

3. Observe the variable:

    APP_CERT_LOCATION = ‘/etc/pki/tls/certs/ca-bundle.crt’ in the live_qpylib.py

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.

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.

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 127.0.0.1 with a port that is available. Example interface: 127.0.0.1:8080.
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: 127.0.0.1 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.

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="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/js/bootstrap.min.js"></script>

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.

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

 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.

• root
• admin
• administrator
• SYSTEM
• Generic users such as user, user1, user2, user3
• Generic users such as qradar, qradar1, qradar2
• Generic users such as testuser1, testuser2, testuser3

• 10.0.0.0 - 10.255.255.255
• 172.16.0.0 - 172.31.255.255
• 192.168.0.0-192.168.255.255
• 198.51.100.0–198.51.100.255
• 203.0.113.0–203.0.113.255

• 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
• example.com
• example.net