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

Secure Coding

With 95 percent of Web applications having software security vulnerabilities secure coding has never been more important.

With 95 percent of Web applications having software security vulnerabilities secure coding has never been more important. 80 percent of all web application have cross-site scripting vulnerabilities on them and 62 percent have more dangerous SQL injection vulnerabilities. If organizations follow simple secure coding practices a majority of these vulnerabilities can be eliminated.
With these vulnerabilities eliminated; the attack surface of your organization is greatly diminished ensuring the confidentiality, integrity and availability of your business critical web applications.
This article will talk about high-level application security concepts, Java security, .NET security, and web application security vulnerabilities and remediation steps.
Secure coding has to be implemented early in the software development process to ensure the application is secure and free from most vulnerabilities. Security is based on the remediation of design flaws and bug flaws.
Bug flaws are the Cross Site Scripting vulnerabilities and SQL injection vulnerabilities were design flaws are the improper use of authorization and cryptography to protect a web application. Both bugs and design flaws must be remediated to have a secure application.
Secure coding starts with senior management implementing a secure coding culture and giving developers the time and the tools to remediate software security vulnerabilities. Education is always important. A developer must be taught to write secure code in order for your application to be secure. Lunch and learns and training help. Online training is a good way to train many developers the basic concepts of secure coding. Individual specialized training is great to teach developers beyond the basics and the secure coding concepts in the language that they program.

In the above figure it is a good idea to have defense in depth in order to protect the business critical application.

A short checklist of what developers’ should and should not do in beneficial in remediating software security vulnerabilities. An example of this would be that all developers must validate all input and use parameterized queries. A not requirement would be that all developers cannot use MD5 hashing to protect sensitive credentials. Instead they should use something stronger as SHA-256. Telling the developers what they should and shouldn’t do is only beneficial if you show that what could and will eventually happen if they do not follow secure coding policies. A good checklist is as follows:

1. Where is the application? Where does it reside?
2. Who uses the application? What is the use case scenario?
3. Who are the attackers?
4. What does the application do?
5. What are the vulnerabilities in the application?
6. Implement policies that are already being used BSIMM.
7. Use automated review for large applications.
8. Create a secure coding check list.
9. AUDITING AND LOGGING
10. COOKIES AND PASSWORDS
11. TECHNOLOGIES THAT CAN NOT BE USE
12. ATTACKS ON SESSION
13. WHAT COULD AN ATTACKER DO TO YOUR APPLICATION
14. PASSWORD POLICIES
15. GETS AND POSTS
16. ACCESS CONTROL POLICIES
17. VALIDATE ALL INPUT
18. UPLOADS AND DOWNLOADS OF FILES
19. PREVENT XSS
20. PREVENT SQL INJECTION
21. INFORMATION LEAKAGE
22. APPLICATION DENIAL OF SERVICE
23. DOCUMENT SECURITY
24. CENTRALIZE SECURITY
25. CODING RULES
26. TESTING

With training secure coding should be implemented early in the development process whether you are using traditional waterfall methods or agile methods. Implementing security in the requirements and design phase is much more effective than bolting security on once the product is released.
SD3 is important to follow. Secure by design, secure by default and secure by deployment. Following SD3 ensures a holistic approach to application security. Having security best practices like running production applications with least privilege and using white list regular expressions for validation is also helpful. In order to reduce the attack surface of the application it is necessary to only use services that your application requires. The server administrators must turn everything else off. Too often applications are attacked by insecure unused services.
If there is only one aspect of secure coding that needed to be remembered it would be not trusting input and validating all input. This is important whether the input is coming from a user or a system in your web application. User input must be sanitized and checked with length checks, range checks and format checks. It is necessary to use defense in depth and learn from mistakes when attacks happen. Manually reviewing source code with peer code reviews and static code analysis find security bugs early. Threat modeling and use case scenarios find design bugs early. Having an internal application security department or third party test the web application with penetration testing and ethical hacking verifies the vulnerabilities have been fixed to an acceptable level to publish the application to users.
Secure code must be: seamless, easy to understand, cognizant of attack, unobtrusive, resilient, error tolerant.

The secret to the CSSLP roles a CSSLP plays in an organization

So you want to be a CSSLP.   Why is it important to become one and what will you learn?  Who are the stake holders in the organization?  

Roles a CSSLP plays within his/ her organization

• Provides a holistic approach to software security needs
• Gives advice regarding designing, developing and deploying secure software
• Maintains knowledge on the latest software security technologies
• Assists in meeting the assurance of compliance to regulations
• Affirms compliance to the policy and procedures set

 

 

 

 

Matt Parsons, CISSP, MSM

mparsons@parsonsisconsulting.com

 

 

 

https://www.isc2.org/uploadedFiles/Landing_Pages/Version_1/CSSLP-Prof-Web.pdf

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

Apple hacked!! Ethical hackers personal information hacked at Apple

My fiancé was trying to download a movie today from iTunes when the security certificate was marked as invalid.  My first thought was did Apple get hacked?   She was trying to download the Jackie Robinson movie, 42.   I didn’t think anything of it and went back to my normal Sunday evening routine.   I was outside playing with our dogs in the yard when my iPhone alerted me of a new message.  

The message I received was the following.  

I then did a little research and found out that Apple was indeed hacked and they were doing major over runs for maintenance.   Part of the problem is that first and foremost I am a an application security engineer and apple developer second.  I have been programming for 15 years and doing application security for 11 of those years.  I have been an apple developer for two years learning cocoa daily to one day strike it rich on an apple development idea. 

I was then thinking.   Apple has all of my sensitive information.   They have my social security number, my credit card, my name and address and my bank account number to deposit my application sales at least 60 percent of it to my bank account while apple profits 40 percent.  

I was thinking that man;  I am an ethical hacker and I got hacked.   It was not a good feeling.  It was a similar feeling when I found out my veteran’s information was hacked and they enrolled me in credit monitoring.  

I felt like a victim.   My career goal in life is to make more applications more secure.   I actually interviewed a few times with the apple development team and they told me I was not smart enough.   I do know this; if I was working with Apple, I would have been smart enough to encrypt all sensitive information.   I would have ensured that the confidentiality, integrity and availability of the application was met.  

I am not sure how this attacked happened but I am guessing from a web application vulnerability.   I believe if Apple hired a competent 3rd party unbiased application security engineer this would not have happened.   Attackers use the same tools and techniques that application security professionals do.   A thorough penetration test and a secure application review could have prevented this.  I pray for other consumers sake and companies that more companies take application security more seriously and reach out to non profit organizations like the open web application security project by training developers and hiring ethical third party security engineers to do software reviews to ensure the confidentiality, integrity and availability of data in systems and putting the proper security controls in place to prevent this from happening in the future.  

 

 

I hope that the most successful company getting hacked is a wake up call.   We need to train developers to program applications more securely and value the competent ethical third party application security engineers that review these applications.  

 

Matt Parsons, CISSP, MSM, CWASE

mparsons@parsonsisconsulting.com

 

 

http://allthingsd.com/20130721/apple-developer-center-was-hacked-site-remains-down-while-company-overhauls-security/

http://www.businessinsider.com/apple-developers-site-hacked-2013-7

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

Iphone programming getting started

My new passion besides software security is Iphone and cocoa development.  I will guide you through a simple Hello World application.  

 

 

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.