Top 10 Bad Coding Practices Lead to Security Problems

Top 10 Bad Coding PracticesTop 10 Bad Coding Practices
Lead to Security ProblemsLead to Security Problems
Narudom Roongsiriwong, CISSPNarudom Roongsiriwong, CISSP
MiSSConf(SP3) Apr 1, 2017MiSSConf(SP3) Apr 1, 2017
Top 10 Bad Coding PracticesTop 10 Bad Coding Practices
Lead to Security ProblemsLead to Security Problems
Narudom Roongsiriwong, CISSPNarudom Roongsiriwong, CISSP
MiSSConf(SP3) Apr 1, 2017MiSSConf(SP3) Apr 1, 2017

WhoAmI
● Lazy Blogger
– Japan, Security, FOSS, Politics, Christian
– http://narudomr.blogspot.com
● Information Security since 1995
● Web Application Development since 1998
● Head of IT Security and Solution Architecture,
Kiatnakin Bank PLC (KKP)
● Consultant for OWASP Thailand Chapter
● Committee Member of Cloud Security Alliance (CSA),
Thailand Chapter
● Consulting Team Member for National e-Payment project
● Contact: narudom@owasp.org

Disclaimer
● The Top 10 list is from code review in my
organization and may not be applied globally.
● Code example in this presentation is mainly in Java.
Specific languages will be notified upon examples

“eval” Function
● Applicable Language: Java, Javascript, Python, Perl,
PHP, Ruby and Interpreted Languages
eval(code_to_be_dynamically_executed);
1

“eval” Function - Security Problems
● Confidentiality: The injected code could access
restricted data / files.
● Access Control: In some cases, injectable code
controls authentication; this may lead to a remote
vulnerability.
● Integrity: Code injection attacks can lead to loss of
data integrity in nearly all cases as the control-plane
data injected is always incidental to data recall or
writing.
● Non-Repudiation: Often the actions performed by
injected control code are unlogged.
● Additionally, code injection can often result in the
execution of arbitrary code. 1

“eval” Function: Reference
● MITRE CWE-95 - CWE-95: Improper Neutralization
of Directives in Dynamically Evaluated Code ('Eval
Injection')
● OWASP Top Ten 2013 Category A3 - Cross-Site
Scripting (XSS)
1

Ignore Exception
class Foo implements Runnable {
  public void run() {
    try {
      Thread.sleep(1000);
    } catch (InterruptedException e) {
      // Ignore
    }
  }
}
2

Ignore Exception - Security Problems
● An attacker could utilize an ignored error condition
to place the system in an unexpected state that
could lead to the execution of unintended logic and
could cause other unintended behavior.
● Many conditions lead to application level DoS
(Denial of Service)
2

Ignore Exception: How to Avoid
● Catch all relevant exceptions.
● Ensure that all exceptions are handled in such a way
that you can be sure of the state of your system at
any given moment.
volatile boolean validFlag = false;
do {
try {
// If requested file does not exist,
// throws FileNotFoundException
// If requested file exists, sets validFlag to true
validFlag = true;
} catch (FileNotFoundException e) {
// Ask the user for a different file name
}
} while (validFlag != true);
// Use the file
2

Ignore Exception: Reference
● CERT, ERR00-J. - Do not suppress or ignore checked
exceptions
2

Throw Generic Exception
● Applicable Language: C++, Java, C# and other .NET
languages
public void doExchange() throws Exception {
…
}
if (s == null) {
throw new RuntimeException("Null String");
}
3

Throw Generic Exception - Security Problems
● Integrity: A caller cannot examine the exception to
determine why it was thrown and consequently
cannot attempt recovery
3

Throw Generic Exception: How to Avoid
● Declares a more specific exception class in the
throws clause of the method
● Methods can throw a specific exception subclassed
from Exception or RuntimeException.
public void doExchange() throws IOException {
…
}
if (s == null) {
throw new NullPointerException
("Null String");
}
3

Throw Generic Exception: Reference
● MITRE, CWE-397 - Declaration of Throws for
Generic Exception
● CERT, ERR07-J. - Do not throw RuntimeException,
Exception, or Throwable
3

Expose Sensitive Data or Debug Statement
● Debug statements are always useful during
development.
● But include them in production code - particularly in
code that runs client-side - and you run the risk of
inadvertently exposing sensitive information.
private void DoSomething ()
{
// ...
Console.WriteLine
("so far, so good...");
// ...
}
4
C#

Expose Sensitive Data or Debug Statement:
Security Problems
● In some cases the error message tells the attacker
precisely what sort of an attack the system will be
vulnerable to
4

How to Avoid
● Do not leave debug statements that could be
executed in the source code
● Do not allow sensitive data to go outside of the
trust boundary and always be careful when
interfacing with a compartment outside of the safe
area
4

Reference
● OWASP Top Ten 2013 Category A6 - Sensitive Data
Exposure
● MITRE, CWE-215 - Information Exposure Through
Debug Information
4

Compare Floating Point with Normal Operator
● Due to rounding errors, most floating-point
numbers end up being slightly imprecise.
● However, it also means that numbers expected to
be equal (e.g. when calculating the same result
through different correct methods) often differ
slightly, and a simple equality test fails.
float a = 0.15 + 0.15
float b = 0.1 + 0.2
if(a == b) // can be false!
if(a >= b) // can also be false!
5

Compare Floating Point with Normal Operator:
Security Problems
● Integrity: Comparing two floating point numbers to
see if they are equal is usually not what you want
5

How to Avoid
● No silver bullet, choose the solution that closes
enough to your intention
● How to compare
– Integer Comparison
bool isEqual = (int)f1 == (int)f2;
bool isEqual = (int)(f1*100) == (int)(f2*100);
// multiply by 100 for 2-digit comparison
– Epsilon Comparison
bool isEqual = fabs(f1 – f2) <= epsilon;
5

Reference
● MISRA C:2004, 13.3 - Floating-point expressions
shall not be tested for equality or inequality.
● MISRA C++:2008, 6-2-2 - Floating-point expressions
shall not be directly or indirectly tested for equality
or inequality
5

Not Validate Input
● The software receives input from an upstream
component, but it does not neutralize or incorrectly
neutralizes special elements that could be
interpreted as escape, meta, or control character
sequences when they are sent to a downstream
component.
6

Not Validate Input: Security Problems
● As data is parsed, an injected/absent/malformed
delimiter may cause the process to take unexpected
actions
6

Not Validate Input: How to Avoid
● Assume all input is malicious.
● Use an "accept known good" input validation
strategy, i.e., use a whitelist of acceptable inputs
that strictly conform to specifications.
● Reject any input that does not strictly conform to
specifications, or transform it into something that
does
6

Not Validate Input: Reference
● OWASP Top Ten 2013 Category A1 - Injection
● OWASP Top Ten 2013 Category A3 - Cross-Site
Scripting (XSS)
6

Dereference to Null Object
● Occurs when the application dereferences a pointer
that it expects to be valid, but is NULL or disposed
● 3 major cases are
– Using an improperly initialized pointer
– Using a pointer without checking the return value
– Using a pointer to destroyed or disposed object
● Applicable Language: C, C++, Java, C# and other
.NET languages
7

Using An Improperly Initialized Pointer
7
private User user;
public void someMethod() {
// Do something interesting.
...
// Throws NPE if user hasn't been properly initialized.
String username = user.getName();
}
What will “username” is?

Using a Pointer Without Checking the Return Value
String cmd = System.getProperty("cmd");
cmd = cmd.trim();
What if no property “cmd”?
7

Using a Pointer to Destroyed Or Disposed Object
public FileStream WriteToFile(string path,
string text)
{
using (var fs = File.Create(path))
{
var bytes = Encoding.UTF8.GetBytes(text);
fs.Write(bytes, 0, bytes.Length);
return fs;
}
}
What will be returned?
C#
7

Dereference to Null Object: Security Problems
● Availability: Failure of the process unless exception
handling (on some platforms) is available, very
difficult to return the software to a safe state of
operation.
● Integrity: In some circumstances and environments,
code execution is possible but when the memory
resource is limited and reused, errors may occur.
7

Dereference to Null Object: How to Avoid
● Checking the return value of the function will
typically be sufficient, however beware of race
conditions (CWE-362) in a concurrent environment.
●
● This solution does not handle the use of improperly
initialized variables (CWE-665).
7

Dereference to Null Object: Reference
● MITRE, CWE-476 - NULL Pointer Dereference
● CERT, EXP34-C. - Do not dereference null pointers
● CERT, EXP01-J. - Do not use a null in a case where an
object is required
7

Not Use Parameterized Query
String query = "SELECT * FROM accounts WHERE
custID='" + request.getParameter("id") + "'";
http://example.com/app/accountView?id=' or
'1'='1
8

Not Use Parameterized Query :
Security Problems
● SQL Injection is one of the most dangerous web
vulnerabilities. So much so that it's the #1 item in
the OWASP Top 10.
● It represents a serious threat because SQL Injection
allows evil attacker code to change the structure of
a web application's SQL statement in a way that can
– Steal data
– Modify data
– Potentially facilitate command injection to the
underlying OS
8

What is Parameterized Query?
● Prepared statements with variable binding
● All developers should first be taught how to write
database queries.
● Parameterized queries force the developer to first
define all the SQL code, and then pass in each
parameter to the query later.
● This coding style allows the database to distinguish
between code and data, regardless of what user
input is supplied.
● Prepared statements ensure that an attacker is not
able to change the intent of a query, even if SQL
commands are inserted by an attacker.
8

Safe Java Parameterized Query Example
String custname = request.getParameter("customerName");
String query = "SELECT account_balance FROM user_data WHERE
user_name = ? ";
PreparedStatement pstmt = connection.prepareStatement(query);
pstmt.setString(1, custname);
ResultSet results = pstmt.executeQuery( );
8

Safe C# .NET Parameterized Query Example
String query = "SELECT account_balance FROM user_data
WHERE user_name = ?";
try {
OleDbCommand cmd = new OleDbCommand(query, conn);
cmd.Parameters.Add(new OleDbParameter("customerName",
CustomerName Name.Text));
OleDbDataReader reader = cmd.ExecuteReader();
// …
} catch (OleDbException se) {
// error handling
}
8

Not Use Parameterized Query: Reference
● MITRE, CWE-89 - Improper Neutralization of Special
Elements used in an SQL Command
● MITRE, CWE-564 - SQL Injection: Hibernate
● MITRE, CWE-20 - Improper Input Validation
● MITRE, CWE-943 - Improper Neutralization of
Special Elements in Data Query Logic
● CERT, IDS00-J. - Prevent SQL injection
● OWASP Top Ten 2013 Category A1 - Injection
● SANS Top 25 - Insecure Interaction Between
Components
8

Hard-Coded Credentials
public final Connection getConnection()
throws SQLException {
return DriverManager.getConnection(
"jdbc:mysql://localhost/dbName",
"username", "password");
}
9

Hard-Coded Credentials: Security Problems
● If an attacker can reverse-engineer a software and
see the hard-coded credential, he/she can break
any systems those contain that software
● Client-side systems with hard-coded credentials
propose even more of a threat, since the extraction
of a credential from a binary is exceedingly simple.
9

9) Hard-Coded Credentials: Reference
● MITRE, CWE-798 - Use of Hard-coded Credentials
● MITRE, CWE-259 - Use of Hard-coded Password
● SANS Top 25 - Porous Defenses
● CERT, MSC03-J. - Never hard code sensitive
information
● OWASP Top Ten 2013 Category A2 - Broken
Authentication and Session Management
9

Back-Door or Secret Page
● Developers may add "back door" code for
debugging or testing (or misuse) purposes that is
not intended to be deployed with the application.
● These create security risks because they are not
considered during design or testing and fall outside
of the expected operating conditions of the
application.
10

Back-Door or Secret Page: Security Problems
● The severity of the exposed debug application will
depend on the particular instance.
● It will give an attacker sensitive information about
the settings and mechanics of web applications on
the server
● At worst, as is often the case, it will allow an
attacker complete control over the web application
and server, as well as confidential information that
either of these access.
10

Back-Door or Secret Page: Reference
● MITRE, CWE-489 - Leftover Debug Code
10

Top 10 Bad Coding Practice
1. “eval” Function
2. Ignore Exception
3. Throw Generic Exception
4. Expose Sensitive Data or Debug Statement
5. Compare Floating Point with Normal Operator
6. Not validate Input
7. Dereference to Null Object
8. Not Use Parameterized Query
9. Hard-Coded Credentials
10. Back-Door or Secret Page

Top 10 Bad Coding Practices Lead to Security Problems

Top 10 Bad Coding Practices Lead to Security Problems

In this document

More Related Content

What's hot

Viewers also liked

Similar to Top 10 Bad Coding Practices Lead to Security Problems

More from Narudom Roongsiriwong, CISSP

Recently uploaded

Top 10 Bad Coding Practices Lead to Security Problems