Category: security

Total 22 Posts

Cyber Security Links from March 2010 SW Engineering Notes

The following links were published in the March 2010 ACM SIGSOFT Software Engineering Notes in the "Surfing the Net for Software Engineering Notes" by Mark Doernhoefer. This issues topic was Cyber Security.

 

By - On 2010-07-25 - in security

Douglas Crockford – Quality

A coworker pointed me to the following video: Quality Software Development by Yahoo Architect Douglas Crockford (181 MB). The presentation from from the Yahoo 2007 FrontEnd Engineering Summit (March 7-8, 2007).

Below are my notes of the slide titles.

  • The Software Crisis
  • Craft vs Engineering
  • Computer Science has not taught us how to manage software projects
  • Software Construction (Good and Bad Analogy)
  • Nature of Software
  • Programming is Difficult
  • Lack of Metrics
  • Lines of Code – not good
  • Programmers are optimists
  • Programmers do not understand how they spend their time
  • Actual time typing is pretty small
  • Skeptical of anything that requires more keystrokes
  • Programming is a social activity
  • Cost of Innovation
  • Legacy
  • Leaps (of productivity? software capability?)
  • Object Oriented Programming (History)
  • Failed Leaps
  • Software does not have enough self awareness to be afraid of bugs
  • Bugs
  • Snake Oil / Silver Bullets
  • Mythical Man Month (1975)
  • Literate Programming (Knuth)
  • Significant difference in individual ability
  • Surgical Team (Harlan Mills)
  • Incrementalism
  • Beta (Perpetually Unfinished)
  • Application triad (skill, technology, requirements)
  • Feature Cost
  • Code Value
  • Code Quality (Micro and Macro View)
  • Simplest thing to enhance value of codebase – make more readable
  • Yahoo Javascript coding convention
  • Programs are a medium of intentional communications
  • Good architecture – necessary structure to keep from collapsing
  • How do we change a correct program into another correct program?
  • Cruft – “Software Scar Tissue”
  • Causes of Cruft
  • Bloat – “Software Cancer”
  • Insecurity
  • Cruft accumulates -> complexity groups -> progress slows
  • Refactoring
  • Sometimes it is best to start over
  • The pain of the crash
  • The illusion of completion
  • An experienced team can cross that ground again very quickly
  • Conclusion

 

By - On 2010-07-17 - in process improvement, project management, requirements, security, software engineering

2010 CWE/SANS Top 25 Most Dangerous Programming Errors

The 2010 CWE (Common Weakness Enumeration) / SANS Top 25 Most Dangerous Programming Errors has been released. The full report should be required reading for all web programmers and testers. A pdf version is also available.

Here are the 25 items:

  1. Failure to Preserve Web Page Structure (‘Cross-site Scripting’)
  2. Improper Sanitization of Special Elements used in an SQL Command (‘SQL Injection’)
  3. Buffer Copy without Checking Size of Input (‘Classic Buffer Overflow’)
  4. Cross-Site Request Forgery (CSRF)
  5. Improper Access Control (Authorization)
  6. Reliance on Untrusted Inputs in a Security Decision
  7. Improper Limitation of a Pathname to a Restricted Directory (‘Path Traversal’)
  8. Unrestricted Upload of File with Dangerous Type
  9. Improper Sanitization of Special Elements used in an OS Command (‘OS Command Injection’)
  10. Missing Encryption of Sensitive Data
  11. Use of Hard-coded Credentials
  12. Buffer Access with Incorrect Length Value
  13. Improper Control of Filename for Include/Require Statement in PHP Program (‘PHP File Inclusion’)
  14. Improper Validation of Array Index
  15. Improper Check for Unusual or Exceptional Conditions
  16. Information Exposure Through an Error Message
  17. Integer Overflow or Wraparound
  18. Incorrect Calculation of Buffer Size
  19. Missing Authentication for Critical Function
  20. Download of Code Without Integrity Check
  21. Incorrect Permission Assignment for Critical Resource
  22. Allocation of Resources Without Limits or Throttling
  23. URL Redirection to Untrusted Site (‘Open Redirect’)
  24. Use of a Broken or Risky Cryptographic Algorithm
  25. Race Condition

 

By - On 2010-02-27 - in security, web testing

How to Verify that HTTP TRACE is Disabled – Telnet Disabled

In a prior post, I described how to use telnet to verify that the HTTP TRACE command is disabled. A commenter asked:

What if telnet is actively being blocked… is there another way to invoke the TRACE request in an attempt to verify whether the potential vulnerability exists?

My immediate reaction was that I needed to research how to do this. What a fool I am…

The fact of the matter is that if an HTTP connection is able to connect to the server than the method I described will still work. Because we are using telnet to impersonate a browser – connecting via port 80 – even if telnet is blocked (usually port 23), using telnet via port 80 will still work. If the browser can connect via this way, so can telnet via port 80.

 

By - On 2009-01-10 - in security, web testing

How to Verify that HTTP TRACE is Disabled

In the past, the TRACE command in the HTTP specification was considered a “safe” command. However, due to the information disclosed combined with other cross-domain exploits, TRACE is no longer considered safe. See US-CERT Vulnerability Note VU#867593 for more information.

I was asked how to verify that the TRACE command (in Apache) is disabled. The easiest way to do this is to use telnet. Launch telnet.

telnet hostname 80
Now, we can issue the TRACE command for a given url.

TRACE /index.html HTTP/1.0


If TRACE is enabled, you will get output that looks something like this:

HTTP/1.1 200 OK
Date: Fri, 05 Dec 2008 05:59:45 GMT
Server: Apache/2.2.8 (Ubuntu) PHP/5.2.4-2ubuntu5.3 with Suhosin-Patch
Connection: close
Content-Type: message/http

TRACE /index.html HTTP/1.0

Connection closed by foreign host.

Now, if TRACE is disabled, the output will look like this:

HTTP/1.1 405 Method Not Allowed
Date: Mon, 08 Dec 2008 21:26:13 GMT
Server: Apache/2.2.8 (Ubuntu) PHP/5.2.4-2ubuntu5.4 with Suhosin-Patch
Allow:
Content-Length: 347
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>405 Method Not Allowed</title>
</head><body>
<h1>Method Not Allowed</h1>
<p>The requested method TRACE is not allowed for the URL /index.html.</p>
<hr>
<address>Apache/2.2.8 (Ubuntu) PHP/5.2.4-2ubuntu5.4 with Suhosin-Patch Server at localhost Port 80</address>
</body></html>
Connection closed by foreign host.

 

By - On 2008-12-08 - in security, web testing

Web Security Testing Links

I recently completed an overview of web security testing for my team. Below are the links I used as resources. I consider the OWASP Testing Guide to be the most useful.

Payment Card Industry Security Standards
PCI Security Standards Council – https://www.pcisecuritystandards.org/
PCI Data Security Standard – https://www.pcisecuritystandards.org/pdfs/pci_dss_v1-1.pdf

Open Web Application Security Project (OWASP)
OWASP Main Site – http://www.owasp.org
OWASP Top 10 (2007) Web Application Vulnerabilities – http://www.owasp.org/index.php/Top_10_2007
OWASP Testing Guide (v2) – http://www.owasp.org/index.php/OWASP_Testing_Guide_v2_Table_of_Contents

SANS Institute (SANS stands for SysAdmin, Audit, Network, Security)
SANS Main Site – http://www.sans.org
SANS Top-20 Internet Security Attach Targets – http://www.sans.org

United States Computer Emergency Readiness Team (US-CERT)
US-CERT Main Site – http://www.us-cert.gov/
US-CERT Security Alerts (Technical) – http://www.us-cert.gov/cas/techalerts/
US-CERT Security Bulletins – http://www.us-cert.gov/cas/bulletins/

Vendor Sites and Resources
SPI Dynamics – http://www.spidynamics.com/
     
White Papers – http://www.spidynamics.com/spilabs/education/whitepapers.html

     
Cross Site Scripting White Paper – http://www.spidynamics.com/assets/documents/SPIcross-sitescripting.pdf

     
SQL Injection White Paper – http://www.spidynamics.com/assets/documents/WhitepaperSQLInjection.pdf

Fortify Software – http://www.fortifysoftware.com/
     
Fortify Taxonomy: Software Security Errors – http://www.fortifysoftware.com/vulncat/

 

By - On 2007-06-13 - in security, web testing

Web Site Security Testing – Quick List of Things to Check

I am on the lookout for resources that will help my team with security testing. Usually, security is not an items that is considered up front when planning the testing of an application. A project I am working on now was built from the ground up — so it did not / could not rely on the security infrastructure in place in existing applications. I went looking for a list of items to check and came across the Open Web Application Security Project (OWASP) site.

OWASP has a Top Ten project which is a list of what they consider the most critical web security flaws. It appears that it is updated on a yearly basis. There is a lot of detail available, but for a quick list of things to check in a web application, this page is the place to begin.

The 2006 OWASP Top Ten list of critical web security flaws is:

  1. Unvalidated Input
  2. Broken Access Control
  3. Broken Authentication and Session Management
  4. Cross Site Scripting
  5. Buffer Overflow
  6. Injection Flaws
  7. Improper Error Handling
  8. Insecure Storage
  9. Application Denial of Service
  10. Insecure Configuration Management

 

By - On 2007-04-09 - in security, web testing

Web Site Security Testing – Directory Listing

One of the projects I am working on is running in a new httpserver instance. One of the things that I have discovered is that many of the things that we put in place regarding web site security need to be recreated in this new application.

As a matter of course, I went to check if it was possible to get a directory listing of the images directory. I was able to do so. Looking at the structure of the site, I was able to get directory listing of all subdirectories in the site. I needed to discuss with the developers why this is not a good idea. Tonight, I came across the following link that describes why this is a threat: [Directory Indexing] Threat Classification – Web Application Security Consortium

 

By - On 2007-04-04 - in security, web testing

Trustworthy Software Systems

I attended a great lecture by Professor Larry Bernstein of the Stevens Institute of Technology. More on Professor Bernstein can be found at his site.

The topic of the presentation was “Trustworthy Software Systems”. Professor Bernstein is a great speaker and shows genuine enthusiasm for his work. He defines trustworthy software as being safe, reliable and secure. On one slide, he defines these terms as:

  • safe – does no harm
  • reliable – no crashes or unexpected behavior
  • secure – no hacking possible

    • He points out that the requirements which make a system trustworthy are non-functional.

    He referred the audience several time to “Trustworthy Systems Through Quantitative Software Engineering ” by Larry Bernstein and C. M. Yuhas. I am planning on becoming more familiar with his work in this area.

     

    By - On 2007-02-24 - in security, system testing, web testing