Java and .NET security

Java Security

http://www.oracle.com/technetwork/java/javase/tech/index-jsp-136007.html

Java has many built in security features that developers of your organization need to use.   It is best not to build your own cryptography methods but use well established classes that have been tested and verified.

Java is has many built in security mechanisms that other languages do not including the following:

1.     Strong data typing

2.     Automatic memory management

3.     Bytecode verification

Cryptography

·       Comprehensive API with support for a wide range of cryptographic services including digital signatures, message digests, ciphers (symmetric, asymmetric, stream & block), message authentication codes, key generators and key factories

·       Support for a wide range of standard algorithms including RSA, DSA, AES, Triple DES, SHA, PKCS#5, RC2, and RC4.

Authentication and Access Control

·       Abstract authentication APIs that can incorporate a wide range of login mechanisms through a pluggable architecture

·       A comprehensive policy and permissions API that allows the developer to create and administer applications requiring fine-grained access to security-sensitive resources.

 

Secure Communications

APIs and implementations for the following standards-based secure communications protocols: Transport Layer Security (TLS), Secure Sockets Layer (SSL), Kerberos (accessible through GSS-API), and the Simple Authentication and Security Layer (SASL). Full support for HTTPS over SSL/TLS is also included.

Public Key Infrastructure

Tools for managing keys and certificates and comprehensive, abstract APIs with support for the following features and algorithms:

·       Certificates and Certificate Revocation Lists (CRLs): X.509

Certification Path Validators and Builders: PKIX (RFC

·       Certificates and Certificate Revocation Lists (CRLs): X.509

·       Certification Path Validators and Builders: PKIX (RFC 3280), On-line Certificate Status Protocol (OCSP)

·       KeyStores: PKCS#11, PKCS#12

Certificate Stores (Repositories): LDAP, java.util.Collection

http://docs.oracle.com/javase/6/docs/api/java/security/SecureRandom.html

java.security
Class SecureRandom

java.lang.Object   java.util.Random       java.security.SecureRandom 

All Implemented Interfaces:

Serializable

---

public class SecureRandom
extends Random

This class provides a cryptographically strong random number generator (RNG).

A cryptographically strong random number minimally complies with the statistical random number generator tests specified in FIPS 140-2, Security Requirements for Cryptographic Modules, section 4.9.1. Additionally, SecureRandom must produce non-deterministic output. Therefore any seed material passed to a SecureRandom object must be unpredictable, and all SecureRandom output sequences must be cryptographically strong, as described in RFC 1750: Randomness Recommendations for Security.

A caller obtains a SecureRandom instance via the no-argument constructor or one of the getInstance methods:

      SecureRandom random = new SecureRandom();  

Many SecureRandom implementations are in the form of a pseudo-random number generator (PRNG), which means they use a deterministic algorithm to produce a pseudo-random sequence from a true random seed. Other implementations may produce true random numbers, and yet others may use a combination of both techniques.

Typical callers of SecureRandom invoke the following methods to retrieve random bytes:

      SecureRandom random = new SecureRandom();       byte bytes[] = new byte[20];       random.nextBytes(bytes);  

Callers may also invoke the generateSeed method to generate a given number of seed bytes (to seed other random number generators, for example):

      byte seed[] = random.generateSeed(20);  

https://www.owasp.org/index.php/Insecure_Configuration_Management

http://www.troyhunt.com/2012/04/67-of-aspnet-websites-have-serious.html

 https://netbeans.org/kb/docs/javaee/secure-ejb.html

.NET security

            For the .NET portion of the article most of the security vulnerabilities come from insecure configuration management in the web.config file.

The below setting is insecure.  

<configuration>
   <system.Web>
      <customErrors mode="Off">

This one is secure.  

<configuration>  
 <system.Web>
      <customErrors mode="RemoteOnly">

It is a good idea to have a custom error page that states there was a problem please try again and have the user use the back button on the users browser.


Cookies Accessible Through Client-Side Script
In Internet Explorer 6.0, Microsoft introduced a new cookie property called HttpOnly. While you can set the property programmatically, you can set it generically in the site configuration.

Vulnerable

<configuration>
   <system.Web>
      <httpCookies httpOnlyCookies="false">

Secure

<configuration>
   <system.Web>
      <httpCookies httpOnlyCookies="true">

Custom Errors Disabled
When you disable custom errors as shown below, ASP.NET provides a detailed error message to clients by default.

Microsoft OLE DB Provider for ODBC Drivers error ‘80040e14’

([Microsoft][ODBC Microsoft Access Driver] Extra )

In query expression ‘UserID=’’’ AND Password =‘’

/_tblemployees/login3.asp, line 49

Vulnerable

<configuration>
   <system.Web>
      <customErrors mode="Off">

Secure

<configuration>  
 <system.Web>
      <customErrors mode="RemoteOnly">

Having the detailed error message to the user or attacker could give an attacker information leakage about the system to launch an attack on the application.  Displaying the type of language the application is written in, the database type, the web server operating system gives too much information to a would be attacker to compromise the application.   

 Hardcoded Credentials Used

Hardcoded credentials to a production database are really the keys to sensitive intellectual property or customer data.   Anyone that has access to hard coded credentials has access to the database.  

Insecure

<configuration>
   <system.Web>
      <password = rootpassword >

Secure

<configuration>
   <system.Web>
      <authentication mode="Forms">
         <forms>
         </forms>

 So hopefully you have a better understanding of java and .NET security.  A few configuration issues fixed in the web.config can make your application secure and better protect it from hackers.

Matt Parsons, CISSP, MSM

mparsons@parsonsisconsulting.com

CSSLP the beginning: What is secure software development?

 

So lets talk about what we are trying to accomplish becoming a CSSLP.   In order to be a CSSLP you need to understand the basic concepts of software security.  

 

 

 

• Confidentiality– keeping data private that is sensitive.
• Authentication– verifying the entity that they are who they say they are.
• Session management– HTTP is a stateless protocol and this is usually managed by cookies.  States or session are sensitive.
• Integrity-  making sure the books stay straight and that data is not modified
• Authorization-  the entity has the clearance to do what he or she is supposed to do no more or no less.  This also ties with the principle of least privilege.
• Exceptions management– that the software systems handles errors properly and maintains a fail safe secure state.
• Availability–  that the software system is up and running when it needs to, to support the business. 
• Auditing– the who, what, where and when questions to an activity. 
• Configuration management– making sure that that vulnerabilities are not introduced to software systems when making changes. 
  

 

 http://www.isc2.org

Matt Parsons, CISSP, MSM

 

 

 

mparsons@parsonsisconsulting.com

 

 

 

 

 

The secret to the CSSLP the beginning of the journey

I am studying to become a CSSLP.  I have had my CISSP for a number of years and have been a programmer and ethical hacker for ten years.  I have my master’s degree in information security and management science and a bachelor’s degree in information science and human computer interaction.  I work for a very large security company.   I am taking the exam too and wanted to share my knowledge of studying for it with the blogsphere.    

The CSSLP examination tests the breadth and depth of a candidate’s knowledge by focusing on the seven domains which comprise the CSSLP, taxonomy of information security topics:

• Secure Software Concepts – security implications in software development and for software supply chain integrity

• Secure Software Requirements – capturing security requirements in the requirements gathering phase

• Secure Software Design – translating security requirements into application design elements Secure Software Implementation/Coding – unit testing for security functionality and resiliency to attack, and developing secure code and exploit mitigation

• Secure Software Testing – integrated QA testing for security functionality and resiliency to attack

• Software Acceptance – security implication in the software acceptance phase

• Software Deployment, Operations, Maintenance and Disposal – security issues around steady state operations and management of software

CSSLP stakeholders include:

•    Auditors
•    Top Management
•    Business Unit Heads
•    IT Manager
•    Security Specialists
•    Application Owners
•    Developers & Coders
•     Project Managers Team Leads
•    Technical Archietects
•    Quality Assurance Managers
•    Business Analysts
•    Industry Group Delivery Heads
•    Client Side PM

https://www.isc2.org

Thanks Matt Parsons, CISSP, MSM
mparsons@parsonsisconsulting.com

OWASP top 10 2013 Introduction

OWASP top 10 2013

https://www.owasp.org/index.php/Top_10_2013-Table_of_Contents

   * A1-Injection

   * A2-Broken Authentication and Session Management

   * A3-Cross-Site Scripting (XSS)

   * A4-Insecure Direct Object References

   * A5-Security Misconfiguration

   * A6-Sensitive Data Exposure

   * A7-Missing Function Level Access Control

   * A8-Cross-Site Request Forgery (CSRF)

   * A9-Using Components with Known Vulnerabilities

   * A10-Unvalidated Redirects and Forwards

We are going to look at the new OWASP top 10 for 2013 starting with injection to unvalidated redirects and forwards.   We will go through each vulnerability and look at the attack vector, risks, how to exploit and how to remediate to protect an application from attackers. 

Thanks,

Matt Parsons, CISSP, MSM, CWASE

mparsons@parsonsisconsulting.com

Cross Site Scripting and how to remediate

When input isn’t properly validated and encoded Cross Site Scripting or XSS is possible.   This is when an attacker is able to execute a dynamic script.   To prove that a page is vulnerable to XSS I usually just do an alert pop up stating “XSS found by Matt”.   A black hat hacker can use this vulnerability to steal the user’s credentials or mounting phishing attacks or man in the middle attacks.   To remediate this vulnerability all input needs a white list validation scheme accepting only known good input and encode all output to prevent the script from running.  

Matt Parsons, CISSP, MSM, CWASE

mparsons@parsonsisconsulting.com

Why it is important to set the secure attribute on session cookies?

When I do application security assessments I often see the secure attribute not set on session cookies over HTTPS.  It is fine to have non sensitive session cookies like language setting not set to secure but something as sensitive as the session cookie need to be set to secure so an attacker does not steal the session or the victim’s cookies and log on as the victim.