1. SE-1021 Software Engineering II
4/14/2018
SE-1021 Software Engineering II
Week 10, Class 1
Security
Dr. Yoder

2. Slide style: Dr. Hornick
Security
Slides by Dr. Dennis
SE-1021
Dr. Josiah Yoder
Slide style: Dr. Hornick

3. Materials
Dean J., Dean R. Introduction to Programming with Java - A Problem Solving Approach, New York: McGrawHill, Chapter
Outcomes:
Slides:
Links:

4. Outline
Security Principles
Security Practices
Security Exercise

5. Outcomes By the end of the class, you should be able to:
Be able to articulate the three aspects of software security.
Be able to discuss three software practices for security with Java.
Identify code that is at risk for exploitation.
Make simple design changes to make your code more secure.

6. What are some design principles for developing secure software?1.
Security Principles
What are some design principles for developing secure software?

7. Mindful
Creating secure code isn’t easy. You have to be aware of secure coding principles and be mindful of their application.

8. Java Security
Java platform comes with a security architecture that can protect against code from untrusted sources.
No security architecture can defend against security exploits stemming from implementation bugs in trusted code.

9. Software Security
Integrity - the notion that only authorized users can manipulate data via authorized methods and procedures.
Confidentiality - the idea that unauthorized access to information is prevented.
Availability - Authorized users are able to access the system.

10. Secure Design Principles
Principle of Least Privilege - A minimalistic approach to granting access rights to tools and data. This limits data changes and prevents potential damage from occurring.

11. Secure Design Principles
Economy of Mechanism - Systems should be designed as simple and as small as possible. This reduces the likelihood of design and implementation errors that could result in unauthorized access.

12. Secure Design Principles
Open Design - Security of a system and its algorithms should not be dependent on the secrecy of its design or implementation. Security is implemented on proven, open standards.

13. Secure Design Principles
Psychological Acceptability - Implementation should protect a system, but not hamper the users. The program should be just as easy to use, or access, as if the security mechanisms weren’t present.

14. Secure Design Principles
Fail Secure - Limit the amount of information exposed when failing.
Weakest Link - A system is only as strong as its weakest link.

15. What are some practices for secure coding in Java?2.
Secure Practices
What are some practices for secure coding in Java?

16. Program as if your system is under attack.
Be Defensive
Program as if your system is under attack.

17. Secure Practices
“Prefer to have obviously no flaws rather than no obvious flaws”
Design and write code such that it does not require clever logic to see that it is safe.
Avoid duplication
Code and data do not tend to be treated consistently when duplicated.
Establish trust boundaries
Data that crosses boundaries should be sanitized and validated.

18. Secure Practices Encapsulate
Allocate behaviors and provide succinct interfaces. Fields should be private and accessors avoided. An interface, class, package, or module should form a coherent set of behaviors.
Beware of activities that may use disproportionate resources
Requesting large image sizes for vector graphics.
Integer overflows.
Infinite loops.

19. Secure Practices Release resources in all cases
Treat every open operation as if it requires an explicit close operation.
Ensure that any output buffers are flushed in the case that output was otherwise successful. If the flush fails, the code should exit via an exception.
Purge sensitive information from exceptions
Exception objects may convey sensitive information. Consider a FileNotFoundException for a config file.

20. Secure Practices Do not log highly sensitive information
Some information, such as Social Security numbers (SSNs) and passwords, is highly sensitive.
Consider purging highly sensitive from memory after use
It may be appropriate to zero memory containing the data immediately after use rather than waiting for the garbage collection mechanism. (No good way for this in Java)

21. Secure Practices Release resources in all cases
Treat every open operation as if it requires an explicit close operation.
Ensure that any output buffers are flushed in the case that output was otherwise successful. If the flush fails, the code should exit via an exception.
Purge sensitive information from exceptions
Exception objects may convey sensitive information. Consider a FileNotFoundException for a config file.

22. Secure Practices Generate valid formatting
Attacks exploiting special characters as inputs, incorrect escaping, or others to cause incorrect formatting are well-documented.
Use well-tested libraries for output, e.g. xml. If non-exist, create simple classes that cleanly handle formatting and only formatting of the output.
XML and HTML generation requires care
Sanitize untrusted data before including in HTML or XML

23. Secure Practices Limit the extensibility of classes and methods
Design classes and methods for inheritance or declare them final.
Left non-final, a class or method can be maliciously overridden by an attacker.
Validate inputs
Inputs from untrusted sources must be validated before use.

24. Secure Practices Ensure public static final field values are constants
Only immutable values should be stored in public static fields.
Prevent constructors from calling methods that can be overridden
Constructors that call overridable methods give attackers a reference to this before the object has been fully initialized.

25. Secure Exercise - Lab 8 Red Team vs. Blue Team Red Team Blue Team
Your job is to identify ways to crash or exploit the application by running it.
Blue Team
Your job is to identify ways to protect your application by inspecting the code.