Defensive Coding Techniques (Pt. 2) Engineering Secure Software - - PowerPoint PPT Presentation

▶
defensive coding techniques pt 2
SMART_READER_LITE
LIVE PREVIEW

Defensive Coding Techniques (Pt. 2) Engineering Secure Software - - PowerPoint PPT Presentation

Dec 09, 2022 278 likes •482 views

Defensive Coding Techniques (Pt. 2) Engineering Secure Software Last Revised: September 25, 2020 SWEN-331: Engineering Secure Software Benjamin S Meyers 1 Last Time... Always code defensively Validating input Principles

slide-1
SLIDE 1

SWEN-331: Engineering Secure Software Benjamin S Meyers

Defensive Coding Techniques (Pt. 2)

Engineering Secure Software

Last Revised: September 25, 2020 1

slide-2
SLIDE 2

SWEN-331: Engineering Secure Software Benjamin S Meyers

Last Time...

  • Always code defensively
  • Principles

○ Writing insecure code is easy ○ Maintainability still counts ○ Know thy API’s ○ Complexity is the enemy of security ○ Don’t be paranoid ○ Tree of knowledge

  • public static final

2

  • Validating input
  • Sanitizing input
  • Exception handling
  • Subclassing
  • Immutability
  • Concurrency
slide-3
SLIDE 3

SWEN-331: Engineering Secure Software Benjamin S Meyers

Cloning is Insecure (and Medically Unethical!)

  • Every Java object has a clone() method

○ Shallow Copy: Obj Obj2 = Obj1.clone()

3

Obj1 ObjA Val

slide-4
SLIDE 4

SWEN-331: Engineering Secure Software Benjamin S Meyers

Cloning is Insecure (and Medically Unethical!)

  • Every Java object has a clone() method

○ Shallow Copy: Obj Obj2 = Obj1.clone()

4

Obj1 Obj2 ObjA Val

slide-5
SLIDE 5

SWEN-331: Engineering Secure Software Benjamin S Meyers

Cloning is Insecure (and Medically Unethical!)

  • Every Java object has a clone() method

○ Shallow Copy: Obj Obj2 = Obj1.clone() ○ What happens when: Obj1.ObjA.value = “blah”

5

Obj1 Obj2 ObjA Val

slide-6
SLIDE 6

SWEN-331: Engineering Secure Software Benjamin S Meyers

Cloning is Insecure (and Medically Unethical!)

  • Every Java object has a clone() method

○ Deep Copy

■ Object Serialization ■ Defensive Copying ■ Copy Constructors ■ Factory Methods

6

Obj1 Obj2 ObjA ValA ObjB ValB

slide-7
SLIDE 7

SWEN-331: Engineering Secure Software Benjamin S Meyers

Cloning is Insecure (and Medically Unethical!)

  • Every Java object has a clone() method

○ Deep Copy

■ Object Serialization ■ Defensive Copying ■ Copy Constructors ■ Factory Methods

7

public final class Galaxy { // Regular Constructor public Galaxy(Double mass, String name) { this.mass = mass; this.name = name; } // Copy Constructor public Galaxy(Galaxy galaxy) { this(galaxy.getMass(), galaxy.getName()); } public Double getMass() { return mass; } public String getName() { return name; } }

slide-8
SLIDE 8

SWEN-331: Engineering Secure Software Benjamin S Meyers

Cloning is Insecure (and Medically Unethical!)

  • Every Java object has a clone() method

○ Often error-prone ○ Doesn’t do what you think it does ○ Most people don’t abide by the contract

  • Even the Java architects don’t like it

○ The Java Language Secure Coding Guidelines from Oracle recommend not using java.lang.Cloneable entirely ○ Use your own copy mechanism if needed

8

slide-9
SLIDE 9

SWEN-331: Engineering Secure Software Benjamin S Meyers

Don’t Be a Serial Killer!

  • Serialization is often unnecessary; difficult to get right
  • Deserializing is essentially constructing an object without

executing the constructor

○ If you use it, don’t assume the constructor will be executed ○ Can reverse-engineer to violate constructor post-conditions ○ Complex input!

  • Note: serialized != encrypted

○ Confidentiality disclosure ○ Use transient for variables that don’t need serialization

■ e.g. environment info, timestamps, keys

9

slide-10
SLIDE 10

SWEN-331: Engineering Secure Software Benjamin S Meyers

Memory Organization Assumptions

  • Don’t rely upon the memory organization of the compiler/OS
  • e.g. C-code:
  • Lots of problems with this

○ Compilers change ○ OS’s change ○ Development environment vs. customer environment ○ Really difficult to debug

10 10

char a=5; char b=3; *(&a+1)=0; /* b is now 0 */ /* this may work, but not advisable */

slide-11
SLIDE 11

SWEN-331: Engineering Secure Software Benjamin S Meyers

Dead Store Removal

  • Don’t leave sensitive data sitting in memory longer than needed

○ Hibernation features dump RAM to HDD ○ Segfault → core dump → passwords!

  • The following is usually a good idea…
  • … BUT C++ .NET and GCC 3.X will optimize away that last call, since

pwd is never used again ○ Some libraries have specific functions to avoid such

  • ptimizations, e.g. explicit_bzero on OpenBSD

11 11

void GetData(char *MFAddr) { char pwd[64]; if (GetPasswordFromUser(pwd, sizeof(pwd))) { if (ConnectToMainframe(MFAddr, pwd)) { /* Interact with mainframe */ } memset(pwd, 0, sizeof(pwd)); /* Clear password */ } }

slide-12
SLIDE 12

SWEN-331: Engineering Secure Software Benjamin S Meyers

Environment & File Confusion

  • In C/C++, the putenv() and getenv() methods vary between OS

○ Change depending on the compiler and platform ○ Sometimes case-sensitive, sometimes not ○ An attacker can add an environment variable (e.g. to his own JVM) that overrides yours

  • Same with file names in Windows (insensitive) and Linux
  • Do not rely on case sensitivity when interacting with platform

12 12

putenv(“TEST_ENV=foo”); putenv(“Test_ENV=bar”); const char *temp = getenv(“TEST_ENV”); if (temp == NULL) { /* Handle error */ } printf(“%s\n”, temp); /* “foo” on Linux, “bar” on Windows */

slide-13
SLIDE 13

SWEN-331: Engineering Secure Software Benjamin S Meyers

Native Wrappers

  • If you use another language, you inherit all of the risks in that

language

○ e.g. Java Native Interface (JNI) can execute a C program with a buffer overflow

  • Also: treat native calls as external entities

○ Perform input validation and sanitization ○ Loaded at runtime → spoofing opportunity

13 13

slide-14
SLIDE 14

SWEN-331: Engineering Secure Software Benjamin S Meyers

Watch Character Conversions

  • Most apps require Internationalization (I18N) in some form

○ Need to convert one character set to another for translation ○ When apps get big, I18N is usually an afterthought

  • Not all character sets are the same size!

○ Assume 4-bytes for a character? Buffer overrun on Chinese chars ○ Not every byte maps to a character ○ Sometimes multiple bytes map to a single character

  • Recommendations

○ Use unicode (UTF-8 or UTF-16) ○ Don’t write your own converters ○ Check: web servers, database systems, command inputs

14 14

slide-15
SLIDE 15

SWEN-331: Engineering Secure Software Benjamin S Meyers

Let Your GET Mean GET

  • HTTP protocols have different actions

○ GET -- for retrieving data (typically) ○ POST, DELETE, etc. -- modify stuff

  • HTTP protocol specifies that GET actions should never have a

persistent effect (e.g. database)

○ Even though you can encode parameters into URL’s ○ Greatly helps mitigate Cross-Site Request Forgery (CSRF) ○ Rarely respected

  • Good: <a href=“index.jsp?navigation=home”>Home</a>
  • Bad: <a href=“index.jsp?changeName=Bobby”>Change Name</a>

15 15

slide-16
SLIDE 16

SWEN-331: Engineering Secure Software Benjamin S Meyers

DoS in Many Forms

  • Denial of service occurs in many, many ways

○ Overflow the hard drive ○ Overflow memory → page faults ○ Poor hashcodes → constant hash collisions ○ Slow database queries ○ Deadlocks, race conditions, other concurrency issues ○ Network bandwidth issues

  • Recommendations

○ Black-box stress testing ○ White-box, unit-level stress testing ○ Focus less on user inputs, more on the logic ○ Learn the art of profiling, e.g. java -agentlib:hprof

16 16

slide-17
SLIDE 17

SWEN-331: Engineering Secure Software Benjamin S Meyers

Don’t Forget Configuration Files

  • Vulnerabilities can also exist in system configurations

○ e.g. log overflow, hardcoded credentials, authorization problems

  • Makefiles and installation definitions

○ Insecure compiler optimizations, e.g. dead store removal opts. ○ Using out-of-date, vulnerable dependencies

  • Also:

○ I18N configurations ○ General configurations ○ Example configurations

  • Recommendation

○ Bring these up in code inspections ○ Look at the defaults, and what is missing

17 17

slide-18
SLIDE 18

SWEN-331: Engineering Secure Software Benjamin S Meyers

Other Defensive Coding via VOTD

  • Resource exhaustion
  • Check the limits of your input

○ Integer overflows ○ Buffer overflows

  • Don’t trust user input

○ SQL injection ○ XSS ○ OS command injection

  • Error message information

leakage

18 18

  • Secure logging

○ Log overflow ○ (Lack of) Log neutralization

  • Limit use of privileged

features of the language

○ Use the Java security Manager ○ Classloader override ○ Complex file system interaction ○ Reflection abuse ○ More serialization restrictions

slide-19
SLIDE 19

SWEN-331: Engineering Secure Software Benjamin S Meyers

Concept: Attack Surface

  • Most exploits enter in through the UI

○ Often the same interface the users see ○ Hence: input validation and sanitization

  • Attack surface

○ The number and nature of the inputs for a given system ○ Can be quantified ○ Usually compared

  • Attack increases with…

○ More inputs, e.g. new input fields, new features ○ Larger input space for a given input, e.g. allowing a markup language instead of plaintext

19 19