Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
Developer Studies
COMP 150-4: Human Factors in Security and Privacy
1
Lecture 19
Prof. Daniel VotipkaSpring 2021
(some slides courtesy of Michelle L. Mazurek and Adam Aviv)
Administrivia• HW3 due on Thursday (4/15) • Bibliographies should follow the SOUPS template • Upcoming Talks:
• NSA Hot Topics on the Science of Security conference• https://cps-vo.org/group/hotsos/registration
• Jeremiah Onaolapo (Next Thursday @ 3pm) — Tales of Malicious Online Activity
• Link: https://tufts.zoom.us/j/98610939077
2
What we did last time!
3
• End User Breach Notifications • How do users respond? • What do typical notifications look like? • Can we make better notifications?
• Enterprise Breach Notifications
What are we doing today?
4
• Developers are not the enemy either! • Secure development ecosystem • Why do developers make mistakes? • Developers support forums
• How can we make them more secure
Recall Users are not the enemy!
• We have to design security systems with users in mind
• Users may be unable to complete security tasks for a variety of reasons, including the design of the system.
Adams, Anne, and Martina Angela Sasse. "Users are not the enemy." Communications of the ACM 42.12 (1999): 41-46.
Can you think of security/privacy frustrations as an end user that a developer could have prevented? • Confusing password requirements (password policy)
• Privacy policies hard to read
• Developer isn’t knowledgeable enough to be building a system (encryption, authentication)
• Often unknown for users is something’s being done correctly
• Systems are not designed with security in mind, security added as an afterthought (example: financial systems in transit, info sharing via email)
• Breaches: developers make bad choices & that’s why they are happening
Can you name security/privacy requirement that you had to implement (in class/job/for fun)? Was it hard to do? Why?
Personal:
• Security knowledge
• Prior experience
• Personality
Support:
• Language design
• Security analyses
• APIs
• Documentation
Organizational:
• Security vs. profit
• Company culture
• Company processes
Environmental:
• Policies/regulations
• Norms and user expectations
Research Questions
What types of vulnerabilities do developers introduce?
• What causes these vulnerabilities to be introduced?
• What are the most prevalent vulnerabilities?
Build it, Break it, Fix it
Secure programming competition in three parts: • Build-It
‣ Develop to secure spec with open choices ‣ Incentivized for functionality, performance, and security
• Break-It ‣ Teams search for vulnerabilities and produce exploits in each
others’ programs • Fix-It
‣ Fix identified problems
[Ruef et al., 2016]
Mimics real-world in a controlled setting
Secure programming competition in three parts: • Build-It
‣ Develop to secure spec with open choices ‣ Incentivized for functionality, performance, and security
• Break-It ‣ Teams search for vulnerabilities and produce exploits in each
others’ programs • Fix-It
‣ Fix identified problems
[Ruef et al., 2016]
Build it, Break it, Fix it
Analysis Approach
Examined 94 projects with 866 reported breaks • Iterative open coding
‣ Vulnerability type, discovery difficulty, exploitability, and severity
• Used qualitative and quantitative analyses
Vulnerability Types
MistakeNo implementation Misunderstanding
Intuitive Bad Choice
Conceptual ErrorUnintuitive
Vulnerability Types
No implementation
• Missed “intuitive” requirement ‣ No encryption ‣ No access control
Intuitive
Vulnerability Types• Missed “intuitive” requirement
‣ No encryption ‣ No access control
• Missed “unintuitive” requirement ‣ No integrity check ‣ No replay protection
No implementation
UnintuitiveIntuitive
Vulnerability Types
• Made a “bad choice” ‣ Weak algorithm ‣ Homemade encryption
Misunderstanding
Bad Choice
Vulnerability Types
• Made a “bad choice” ‣ Weak algorithm ‣ Homemade encryption
• Made a “conceptual error” ‣ Fixed value ‣ Disabling protections
Misunderstanding
Bad Choice Conceptual Error
Vulnerability Types
MistakeNo implementation Misunderstanding
Intuitive Bad Choice
Conceptual ErrorUnintuitive Least common
Best practices and code review helped
50% 56% 21%
Prevalence
No implementation Misunderstanding Mistake
Unintuitive Bad Choice Conceptual ErrorIntuitive
44%45% 21%16%
Summary
Developers struggle with security concepts • MOOC lectures covered these topics ‣ Education should include practical
examples to display need and assumptions
How Android developers look up information
• What do Android developers do when they encounter a security- or privacy-related issue?
• Which information sources do they use to look up security- or privacy-relevant questions?
• Does the use of Stack Overflow really lead to less secure code than the use of other resources?
• Is the official Android documentation really less usable, resulting in less functional code compared to other resources?
Online Survey of Application Developers
• Emailed 50,000 developers who were listed in the Google Play Store
• 302 people completed the survey, 7 removed
• Final: 295 developers with apps listed in the Google Play Store
• Low conversion rate!
How would you find out whether these resources have an impact on code security?• Break up devs into groups • Give them different docs • Develop secure app • Test results
Change HTTP to HTTPS connections
• Hostname mismatch errors
• Service certificate was issued for a subdomain instead of the top level domain
Inter Process Communication• Set up an intent so that this
application can be called from another application
Treatments
• Stack Overflow • Only use Stack Overflow for looking
up information
• Official Android Documentation • Restrict access to anything at
developer.android.com
• Books • Only use books (in pdf or print) • Pro Android 4 • Android Security Internals
• Free Use • Start at google.com and do
whatever
Recruitment
• 54 Developers • 12 USA • 43 Germany
• 48 Students • 8 Women • 40 Men
• 6 Professional developers
• 20 minute limit to solve the task
• Four tasks in random order
Anything stand out here?
Confidence in solution
“Free to use any resource” are a lot more confident
“Official resources and Stack Overflow (SO) similar confidents, and maybe official the least
Usability of resourcesFree to use any
resource was the most usable
Book the least usable
Book and Office Documentation were
least helpful
Stack Overflow and Free resources viewed
as helpful
Does this make sense to you?
Books and Official viewed as most correct,
closely followed by Stack Overflow
Free resources viewed perhaps least likely to
be correct
Functional (maybe not secure) Correctness
• Overall Functional Correctness:
• 67% Stack Overflow • 66% book • 52% Free choice • 40% official
documentation
What does this say about the task as well as the resources?
Functional (and secure) Correctness
• Security: • 86% official
documentation • 73% book • 66% Free choice • 52% Stack
Overflow
Why was this so good?
Remember, this task was one of the hardest!
Discussion
• What happened? Was this the result you were expecting?
• How can we explain the disparity between usability and secure code?
• Any obvious and problematic limitations in the study?
• Time limit issues?
• Tests for success?
Now that we have the problem (insecure code comes from SO), what would you do with that information? How would you set up a follow-up study? • How much of the code is out there, static analysis on app code • Code reviews to help developers develop secure code • Flag insecure code on stack overflow
How much Stack Overflow code actually make it into Android applications?
• How do security related snippets in Stack Overflow proliferate?
• Actually find all relevant Stack Overflow post for Android and analyze those for security.
IEEE S&P’17
What do you expect to see?
• A lot of copy pasting / direct usage • Time crunch -> a lot of different variety of snippets
Security Code Snippets Found Online
• Cryptography • Java Cryptography Architecture • Java Cryptography Extension
• Secure network communication • Java Secure Socket Extension • Java Generic Security Service • Simple Authentication and Security
Layer
• Reference Libraries (w/usability) • Keyczar • jaysprt
• Public Key Infrastructure • X.509 and Certificate Revocation List
in java.security.cert • Java certificate path API, PKCS#11,
OCSP
• Authentication and Access Control • Java Authentication and
Authorization Service
• Apache TLS/SSL • HttpClient
High Level Findings
• 15% of survey apps contain at least one insecure snippet • Top snippets can be found in 180K (13.8%) of apps • 183K apps were related to TLS (14%) • 21K related to symmetric cryptography (1.4%)
• 500K applications contain a secure snippet (38.82%)
Discussion
• Reflections from your own work flow? • How do you use stack overflow?
• How easily can these snippets be fixed? • What is the responsibility of Stack Overflow?
• What follow up work would you consider?
What’s other work you would do to help developers develop secure code? • Test first development: does this impact code security?
• “gut feeling”: helpful to write code to test, if it passes: secure! • Might increase the time initially • How common might this be? ! probably not, pushed in certain places
69
What we did today!
• Developers are not the enemy either! • Secure development ecosystem • Why do developers make mistakes? • Developers support forums
• How can we make them more secure