Web Admin Blog Real Web Admins. Real World Experience.

2Jun/143

My First Experiences with a Palo Alto Firewall

I've been following Palo Alto as a networking company for a couple of years now.  Their claim is that the days of the port-based firewall are dead and that their application-centric approach is a far better way to enforce your access controls.  Take the HTTP protocol for example.  HTTP typically runs as a service on port 80, but does that mean that everything running on port 80 is HTTP?  As an attacker looking for a way to funnel data out of your organization, why not use the standard HTTP port to send data, since I know you leave it wide open in order for your employees to surf the web.  There's nothing to say that I actually have to be running an HTTP server on the other end and there's nothing on my classic firewall to tell any differently.  At first, I was admittedly a bit skeptical.  I didn't think that you could really tell enough about different applications on the web to be able to separate them out like Palo Alto claims to.  Fortunately, Palo Alto reached out to me and provided me with a brand new PA-200 in an attempt to change my mind.

When the PA-200 arrived, it came with everything that I would need to get it up and running.  That includes the unit itself, a power supply, a D89 to RJ45 console cable, an ethernet cable, and some instructions and warranty information.

20140521_175741

On the front of the unit is four ethernet ports for your devices, a management port, a USB port, a console port, and several status indicator LEDs.

20140521_175845-2

By default, the appliance is configured with ethernet ports 1 and 2 paired as a WAN to LAN link as this is the configuration that the majority of the people who buy it will likely use it for.  That said, by following the instructions to connect your computer up to the management port, you can quickly access the user interface that allows you to change this assignment.

Ethernet Configuration

This shows the ethernet 1 and 2 interfaces as both being a "virtual wire" and here we can see the virtual wire that connects the two.

Virtual Wire

From here, we can take a look at the "zones" and see that our two interfaces have been defined as an untrusted (ethernet 1) and trusted (ethernet 2) zone.

Zones

To think of this a different way, my cable modem WAN connection (ie. the Internet) goes in my "untrust" zone and my local network (ie. LAN) goes in my "trust" zone.  Now all that's left is to set our policy and for ease of management to start with, I set it to allow everything out with a default deny all inbound.

Security Profile

With this configuration I had done enough to be up and running on the device and I immediately started to see data populate the dashboard on the top applications running on my network.

Top Applications

It's color coded based on risk level and the dashboard also provides me a similar view of Top High Risk Applications.  Any of these boxes can be clicked on in order to provide additional data about the protocol, sources, destinations, countries, and more.

Application Information

Now, let me say that while I'm running this on my home internet connection, this thing is a hoss and can do way more than I can throw at it.  With their App-ID technology enabled you can throw 100 Mbps of throughput at it no problem.  In addition to being an application firewall, it also does standard port-based firewalling, VPN, routing, switching, and so much more.  It's so extremely versatile that this thing could easily be placed in a smaller branch office and replace multiple other devices on their network such as a firewall, router, and VPN concentrator.  More functionality for less money...who wouldn't want that?  In addition to these default capabilities, additional licensing can also be obtained to allow you to do URL filtering, malware detection, and more.  Having just gotten this up and running, I'm still exploring the ins and outs of all of the functionality, but it's pretty exciting to have all of this capability in a box that is smaller than the cable modem my ISP provides me.  More posts to come on this as I get deeper into the guts of running my new Palo Alto PA-200 !

13Nov/090

Building an In-House Application Security Assessment Team

This presentation was by Keith Turpin from The Boeing Company.   About three years ago, all of Boeing's assessments were coming from outsourced service providers.  They realized that they were unable to have control over the people and process and had difficulties integrating the controls into the SDLC and decided to bring these functions in house.  The goal of this presentation is to show some of the issues they ran into and how they addressed those problems.  My notes from the presentation are below:

Contraced Services Considerations

  • Some Advantages:
    • Highly skilled
    • Established tools, processes, and standards
    • Unbiased
    • Available as needed
  • Some Disadvantages:
    • Expensive, especially for an extended engagement
    • Less control and flexibility
    • Not familiar with company processes and culture
    • Rotating staff

Planning

  • Considerations for establishing an internal team:
    • Time to staff and train the team
    • Overlap of external and internal teams
    • Development of processes and standards
    • Acquiring necessary tools

Service Model

  • Define the services your team will provide.  This will be greatly influenced by:
    • The team's size and skills
    • The number of applications you have to support
    • The tools available
    • The level of executive support
    • The funding model
      • Who pays for your services
    • The team's role
      • Development support, pre-deployment testing or post deployment auditing and pen testing
13Nov/090

OWASP Top 10 – 2010

This presentation was by Dave WIchers, COO of Aspect Security and an OWASP Board Member.  My notes are below:

What's Changed?

  • It's about Risks, not just vulnerabilities
    • New title is: "The Top 10 Most Critical Web Application Security Risks"
  • OWASP Top 10 Risk Rating Methodology
    • Based on the OWASP Risk Rating Methodology, used to prioritize Top 10
  • 2 Risks Added, 2 Dropped
    • Added: A6 - Security Misconfiguration
      • Was A10 in 2004 Top 10: Insecure Configuration Management
    • Added: A8 - Unvalidated Redirects and Forwards
      • Relatively common and VERY dangerous flaw that is not well know
    • Removed: A3 - Malicious File Execution
      • Primarily a PHP flaw that is dropping in prevalence
    • Removed: A6 - Information Leakage and Improper Error Handling
      • A very prevalent flaw, that does not introduce much risk (normally)
  1. A1- Injection: Tricking an application into including unintended commands in the data sent to an interpreter. (http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet)
  2. A2 - Cross Site Scripting (XSS): Raw data from attacker is sent to an innocent user's browser.  For large chunks of user supplied HTML, use OWASP's AntiSamy to sanitize this HTML to make it safe.  (http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet)
  3. A3 - Broken Authentication and Session Management: Means credentials have to go with every request.  Should use SSL for everything requiring authentication.
  4. A4 - Insecure Direct Object Reference: This is part of enforcing proper "Authorization", along with A7 - Failure to Restrict URL Access.
  5. A5 - Cross Site Request Forgery (CSRF): An attack where the victim's browser is tricked into issuing a command to a vulnerable web application.  Vulnerability is caused by browsers automatically including user authentication data with each request.  (Check out OWASP CSRFGuard, OWASP CSRFTester, http://www.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet)
  6. A6 - Security Misconfiguration: All through the network and platform.  Don't forget the development environment.  Think of all the places your source code goes.  All credentials should change in production.
  7. A7 - Failure to Restrict URL Access: This is part of enforcing proper "authorization", along with A4 - Insecure Direct Object References.
  8. A8 - Unvalidated Redirects and Forwards: Web application redirects are very common and frequently include user supplied parameters in the destination URL.  If they aren't validated, attacker can send victim to a site of their choice.
  9. A9 - Insecure Cryptographic Storage: Storing sensitive data insecurely.  Failure to identify all sensitive data.  Failure to identify all the places that this sensitive data gets stored.  Failure to properly protect this data in every location.
  10. A10 - Insufficient Transport Layer Protection

OWASP Top 10 Risk Rating Methodology

  • Attack Vector (How hard for an attacker to use this flaw - 1 (Easy), 2 (Average), 3 (Difficult))
  • Weakness Prevalence (How often is it found - 1 (Widespread), 2 (Common), 3 (Uncommon))
  • Weakness Detectability (How hard is it for an attacker to find the flaw - 1 (Easy),  2 (Average), 3 (Difficult))
  • Technical Impact (1 (Severe), 2 (Moderate), 3 (Minor))

This is generic across the internet, not specific to any organization.

Started a new "Prevention Cheatsheet Series" that the Top 10 references (XSS, SQL Injection, Transport Layer Security, CSRF, Direct Object Reference).

What is actually being released is RC1 of the Top 10 and they are encouraging people to provide comments through the end of the year and then use that feedback to post the final Top 10 in January 2010.

13Nov/090

Application Security Metrics from the Organization on Down to the Vulnerabilities

This presentation was by Chris Wysopal, the CTO of Veracode.  My notes are below:

"To measure is to know." - James Clerk Maxwell

"Measurement motivates." - John Kenneth Galbraith

Metrics do Matter

  1. Metrics quantify the otherwise unquantifiable
  2. Metrics can show trends and trends matter more than measurements do
  3. Metrics can show if we are doing a good job or bad job
  4. Metrics can show if you have no idea where you are
  5. Metrics establish where "You are here" really is
  6. Metrics build bridges to managers
  7. Metrics allow cross sectional comparisons
  8. Metrics set targets
  9. Metrics benchmark yourself against the opposition
  10. Metrics create curiosity

Metrics Don't Matter (Mike Rothman)

  • It is too easy to count things for no purpose other than to count them
  • You cannot measure security so stop
  • This following is all that matters and you can't map security metrics to them:
    • Maintenance of availability
    • Preservation of wealth
    • Limitation on corporate liability
    • Compliance
    • Shepherding the corporate brand
  • Cost of measurement not worth the benefit

Bad metrics are worse than no metrics

Security Metrics Can Drive Executive Decision Making

  • How secure am I?
  • Am I better off than this time last year?
  • Am I spending the right about of money?
  • How do I compare to my peers?
  • What risk transfer options to I have?

Goals of Application Security Metrics

  • Provide quantifiable information to support enterprise risk management and risk-based decision making
  • Articulate progress towards goals and objectives
  • Provides a repeatable, quantifiable way to assess, compare, and track improvements in assurance
  • Focus activities on risk mitigation in order of priority and exploitability
  • Facilitate adoption and improvement of secure software design and development processes
  • Provide and objective means of comparing and benchmarking projects, divisions, organizations, and vendor products
12Nov/090

The ESAPI Web Application Firewall

This presentation was by Arshan Dabirsiaghi and was about the OWASP ESAPI Web Application Firewall (WAF) project.  My notes are below:

WAF Fallacies (at least in regards to OWASP ESAPI WAF)

  • WAFs add attack surface
  • WAFs can create culture problems
  • WAFs can't fix business logic vulnerabilities
  • WAFs are way too expensive
  • WAFs complicate networks

Why fix in ESAPI WAF vs Fix in code?

  • Changing in ESAPI WAF is just a text file
  • Shorter gap between time discovered and WAF fix vs code fix

Advantages of WAF

  • Performance - Only your rules are checked, plus state is already managed by the app server
  • Capability - being closer to the app lets us do more
  • Process - Rules are closer to application owner, shortening discovery-to-patch time, also fix-to-patch-removal time

Principle: Make common tasks easy, uncommon tasks possible

General virtual patching functionality is easy to understand

Ability to write custom script rules as well "bean-shell-rules"
Fixing Injection Flaws is easy

Can fix business logic flaws with the WAF (missing authentication, missing functional access control, missing data layer access control)

Can add "outbound" security as well

  • Add anti-clickjacking header
  • Set uniform content-type
  • Add HttpOnly flag
  • Add secure flag
  • Detect outbound information
  • Replace outbound information

Takes advantage of early failing to make rules as optimized as possible

Now we see the tool demonstrated with several different vulnerabilities in a real-world application (JForum):

  • Cross-Site Scripting Flaw (JForum XSS flaw is unable to be fixed with a WAF because of dynamic URLs)
  • Unchecked Redirect
  • Add HttpOnly
  • Add anti-clickjacking header
  • Privilege escalation

3 Different WAF Modes

  • Log
  • Block
  • Redirect

Latency with all of the rules turned on is about 5%.  With selected rules is closer to 0%.  Basically an order of n magnitude where n is the number of rules enabled.  Comes out to milliseconds.

12Nov/090

Enterprise Application Security – GE’s Approach to Solving Root Cause

The first presentation of the day that I went to  was by GE's Darren Challey and was about GE's application security program and how he took a holistic approach to securing the enterprise.  My notes on this presentation are below:

Why is AppSec so hard?

  • AppSec changes rapidly (look at difference between 2004, 2007, and 2010 Top 10)
  • Changing landscape
    • Increase skill and talen t pool of technically proficient individuals willing to break the law
    • Growing volume of financially valuable data online
    • Development of criminal markets (black markets) to facilitate conversion to money
  • "Attackers now have effective skills, something to steal, and a place to sell it"
  • Application Security is a complete one-sided game
  • Need to become an enabler (not a barrier)
  • Must inject application security earlier through Guidance, Education, and Tools
  • Must understand the development and deployment process and integrate rather than mandate
  • NIST study on cost to repair defects when found at different stages of software development (http://www.nist.gov/director/prog-ofc/report02-3.pdf)
  • Solving the problem of the enterprise (Culture Change)
  • Success factors
  • Form a mission and strategy
  • Develop policy (but not corporate "mandate")
  • Gain executive buy-in (cost / benefit / risk)
  • Understand the magnitude of problem (metrics)
  • Asset inventory and vulnerability management
  • Develop standards (what should I do and when?)
  • Establish a formal program (strong leadership)
  • Focus on education and training materials
  • Develop in-house expertise, services and "COE"
  • Continuous improvement, measurement, KPI
  • Communicate!
  • Drive a culture change (shared need, WIIFM)
  • Communicate expectations with vendors
  • Implement incentives (and penalties)
  • Digitize after the process is solid (tools)
  • AppSec program mission & structure
  • AppSec program strategy
  • Policy (guidance) -> Standards (Guidance) -> Training (Education) -> Metrics (tools) -> Security tools (tools) -> Inventory & tracking (tools) -> Monitor & Improve

Guidance

  • "GE Application Security Working Group" (Talking to the businesses is critical!  Meet every 2 weeks.)
  • Secure Coding Guidelines
  • Vulnerability Remediation Guide
  • Secure Deployment
  • Quick Reference Card
  • Contractual Language
  • Desk Calendars
  • Metrics: AppSec calendars helped increase visitors to key Guidance materials  (track hits to website docs when certain activities take place)

Education

  • CBT1: Intro to AppSec at GE (60 min for any IT person) - why AppSec is important and what happens when you don't do it
  • CBT2: GE Best Practices for Secure Coding (90 min)
  • CBT3: Attack Profiles & Countermeasures (120 min for security people)
  • Developer Awareness Assessment:
    • 100's of internally-developed questions
    • Randomized questions, timed completion
    • Vendors track their own resutls
    • Allows tailoring of training/awareness programs

Tools

  • - COE AppSec assessment services
  • Vendor framework & Metrics
  • Compliance handbook
  • Common objects repository
  • GE Enterprise Application Security
  • Scanning and Monitoring tools
  • Automation is the way to go (but the tools are not quite there yet)

Metrics

  • Measure Vendor AppSec Performance (Avg % Critical/High Vulnerabilities per Assessment vs % Assessments with Zero Critical/High Vulnerabilities)
  • Is it making a difference (map avg of critical/high vulnerabilities per assessment)

Forming a Center of Excellence

  • Combines the best available people, processes and tools
  • Formal training & defined roles (Comprehensive training program for all auditors to ensure skills are kept current and that auditors can provide more than one type of service)
  • COE Team structure (tools, research, operations, stakeholder management, queue management, application security auditors
  • Application Assessment Types (black/grey box vs white box)
  • Application assessment process (map of the workflow with "swim lanes" of who does each step)
  • Measure number of vulnerabilities and severities
  • Measure customer satisfaction (overall, ease of engagement, responsiveness)
23Mar/090

Assessing Your Web App Manually Without Hacking It

After giving my presentation on "Using Proxies to Secure Applications and More" at the TRISC 2009 conference, I decided to attend the presentation by Robert "RSnake" Hansen and Rob MacDougal entitled "Assessing Your Web App Manually Without Hacking It".  The gist of this presentation was that with a few simple tools (Web Developer Toolbar, NoScript, you web browser) you can spend about an hour looking at the characteristics of a web application in order to determine what types and how many vulnerabilities it may have.  My notes on the presentation are below:

25Sep/080

Cryptography for Penetration Testers – OWASP AppSec NYC 2008

This presentation was on "Cryptography for Penetration Testers" and was by Chris Eng, the Senior Director of Security Research at VeraCode.

The Premise

How much do you really have to know about cryptography in order to detect and exploit crypto weaknesses in web apps.

Goals

  • Learn basic techniques for identifying and analyzing cryptographic data
  • Learn black-box heauristics for recorgnizing weak crypto implementation
  • Apply techniques

The Crypto that Matters in 6 Short Slides

Types of Ciphers

  • Block Ciphers: Operates on fixed-length groups of bits, called blocks.  Block sizes vary depending on the algorithm.  Several different modes of operation for encrypting messages longer than the basic block size.  Example ciphers include DES, 3DES, Blowfish, AES
  • Stream Ciphers: Operates on plaintext one bit at a time

Block Ciphers: Electronic Code Book (ECB) Mode

  • Fixed-size blocks of plaintext are encrypted independently
  • Each plaintext block is substituted with ciphertext block, like a codebook
  • Weaknesses: Structure in plaintext is reflected in ciphertext.  Ciphertext blocks can be modified without detection.

Bliock Ciphers: Cipher Block Chaining (CBC) Mode

  • Each block of plaintext is XORed with the previous ciphertext block before being encrypted
  • Change of message affects all following ciphertext blocks
  • Initialization Vector (IV) is used to encrypt first block

Stream Ciphers

  • Plaintext message is processed byte by byte (as a stream)
  • Key scheduler algorithm generates a keystream using a key and an Initialization Vector (IV combined (XOR) with plaintext bit by bit
  • Encrypt by XORing plaintext with the generated keystream

Common Crypto Mistakes

  • Insecure cipher mode (usually ECB)
  • Inappropriate key reuse
  • Poor key selection
  • Insufficient key length
  • Insecure random number generation
  • Proprietary or home-grown encryption algorithms (Don't do this ever!)

Analysis Techniques

Dealing with Gibberish Data

What do you do when you are pen testing a web application and you encounter data that is not easy to interpret?

  • Cookies
  • Hidden fields
  • Query string parameters
  • POST parameters

How random is it?

  • Output of cryptographic algorithms should be evenly distributed, given a sufficiently large sample size.
  • Tools such as ENT (http://www.fourmilab.ch/random) will calculate entropy per byte, chi-square distribution, arithmetic mean, serial correlation, etc

Observe Characteristics

Is the length a multiple of a common block size?

  • Indicates that the application may be using a block cipher

Is the length the same as a known hash algorithm?

  • For example, MD5 is usually represented as 32 hex characters
  • May also indicate the presence of an HMAC
  • Still may be worthwhile to hash various permutations of known data in case a simple unkeyed hash is being used

Stimulus, Response

Does the length of the token change based on the length of some value that you can supply?

For a block cipher, you can determine the block size by incrementing input one byte at a time and observing when the encrypted output length jumps by multiple bytes (ie, the block size)

How does the token change in response to user-supplied data?

  • Figure out how changing different parts of the input affects the output
  • Is more than one block affected by a single character change in the input?

Deeper Block Cipher Inspection

Are there any blocks of data that seem to repeat in the same token or over multiple tokens?

  • Possibly ECB mode, this doesn't just happen by coincidence

EXAMPLE

Context:  A public-facing web portal for a large ISP.  Used an encrypted cookie to authenticate identity.  A new cookie is issued on each request.  Base64 decoded EE cookies.  Divided by 8 and found 8 byte blocks.  Noticed some repetition in the same position.  The only variable blocks are the last two (possibly a "last accessed" timestamp or similar timeout mechanism).  Register a new account with a username of 'c' x 32, the maximum length permitted, and observe the value of the EE cookie.

'c' x 32 is Perl notation for "cccccccccccccccccccccccccccccccc"

The token is longer, meaning the username is probably stored in the cookie.  Still noticed repition in same position.  Register another account with a username of 'c' x 16 and compare to the EE cookie generated in the previous step.  Didn't see two identical blocks for 'c' x 16 and four identical blocks for 'c' x 32.  Reason is padding.  The username doesn't align perfectly with the block offset.  Want to figure out what position in the cookie the usernaem is located.  Additional user accounts were created with specific usernames in order to determine if there is any initial padding in the first block.  Now you know where the username is in the ciphertext.

Able to successfully subvert the authentication mechanism without any knowledge of the algorithm or the key, based solely on observed patterns in the ciphertext.  The root cause was the insecure cipher mode and the lack of a verification mechanism.  ECB mode shoul dnot be used (use CBC instead).

EXAMPLE

Token values observed in URLs.  Changed every time we logged on to the application.  Never the same for any two sessions or any two users.  Base64 decoded values for several different "stmt" tokens.  Statement numbers were displayed in the browser.  Looked for correlations between statement number and cipher-text.  Conclusion: It looks like a stream cipher.  Use XOR to calculate 10 bytes of the keystream based on the known plain-text (ie. the statement number).  Now try the same things against one of the other collected tokens, such as the one called "Ctxt".  Get ASCII text that allows you to infer what it would say.  Expand it out more and more to get the keystream.  Repeat over and over until you have enough of the key to figure out anything in the application.

Through this iterative process, we can obtain the entire keystream (or rather, a sufficient amount of the keystream to encrypt and decrypt all of the cipher-text we encounter).  Can replace the statement number with another valid statement number and view the contents.

Able to subvert the encryption mechanism without any knowledge of the algorithm or the key based solely on observed patterns in the ciphertext.  They were using RC4 with a unique key generated for each user session.  Root cause of the vulnerability is the re-use of the keystream.

25Sep/080

Practical Advanced Threat Modeling – OWASP AppSec NYC 2008

This presentation was by John Steven who is the Senior Director of Advanced Technology Consulting at Cigital, Inc.

What is a threat?

  • An agent who attacks you?
  • An attack?
  • An attack's consequence?
  • A risk?

What is a threat model?

  • Depiction of the system's attack surface, threats who can attack the system, and assets threats may compromise.
  • Some leverage risk management practices.  Estimate probability of attack.  Weigh impact of successful attack.

Elements of a threat model

  • Structural view
  • Threat actors
  • Assets
  • Attack vectors
  • Privilege/"trust"

Threat

  • Capability: Access to the system, able to reverse engineer binaries, able to sniff the network
  • Skill Level: Experienced hacker, script kiddie, insiders
  • Resources and Tools: Simple manual execution, distributed bot army, well-funded organization, access to private information
  • Threats help encourage thorough throught about how intentions for misuse and determine "out of bounds" scenarios.

A Few Words on STRIDE

  • A conceptual checklist backed by data flow diagrams

Attack Trees

  • Aggregate attack possibilites
  • Use OR, AND
  • Allow for decoration (probability, cost, skills required, etc)

Threat Modeling as a Process

  • Use threat modeling to identify where potential threats exist relative to the architecture, how threats escalate privilege, specify vectors of attack, identifies components and assets worth protecting.

Leading Up to Threat Modeling

  • Identify threats
  • Enumerate doomsday scenarios
  • Document misuse/abuse
  • Diagram structure, assets
  • Annotate diagram with threats
  • Enumerate attack vectors
  • Iterate

Input: Goals, Doomsday Scenarios

Misuse/Abuse Cases (use case view and component view)

Inputs: Security Requirements (specified security features - "128 bit encryption", "software security != security software")

Anchor in Software Architecture

Consider where attacks occur:

  • Top-down: enumerate business objects (sensitive data, privileged functionality)
  • Bottom-Up: enumerate application

Output: Security Assessment & Test Design.  Threat models drive assessments, Test design.  Establish rules of engagement.  Prioritize areas of interest.  Manage a team in risk-based fashion.  Establish a single tie between vulnerability and control.

Application Structure: No "One Size Fits All"

Application Structure: Topology - Coloration shows authorization by role.  Arrows indicate resolution of principal/assertion propagation.  Use structure to separate privilege.

Application Structure: Components - Component diagrams show critical choke points for security controls (input validation, authentication, output encoding).

Application Structure: Frameworks - Showing frameworks indicates where important service contracts exist "up" and "down".

Assets: Flow - Assets exist not only in rest, but also flow through the system.  Use different types of flags to represent data flow of assets.

Use different colored arrows to represent each different attack vector.

Target Using Layered Attacks: Bootstrap later attacks with those that "deliver".  Use one layer to exploit another (net, app).  Combine attacks to reach desired target.

Take Homes

  • Base threat model in software architecture
  • When specific use (cases) and high-level architecture are defined: inventory roles, entitlements, if one doesn't exist and inventory assets, sensitive data, privileged components
  • Enumerate initial attack vectors.  Use common low hanging fruit.
  • Elaborate more attacks.  Find opportunities for privilege escalation.  Layer attacks to target or "hop" to assets.  Fill in gaps by "inventing" attacks.
  • Use threat modeling to drive security testing
25Sep/081

Lotus Notes/Domino Web Application Security – OWASP AppSec NYC 2008

This presentation was by Jian Hui Wang (girl) who is a security professional, but "a nobody in NYC".  Talking about Lotus Notes/Domino web application architecture and security features, web application common development mistakes and fixes, and test methodology.

Lotus Notes/Domino History

Lotus Notes is client and Domino is the server.  Supports multiple protocols with one interface (HTTP, LDAP, SMTP/POP/IMAP, file sharing).  Strong on workflow application and collaborative application.  Used by .gov, .edu, .com.  Google search shows 66 million notes databases facing the internet.  People use it because it's easy to develop and deploy a simple application, granular access control, good logging method, and it integrates well with e-mails.

Notes Databases

Notes databse is building block of Domino application (.nsf or .ntf).  Notes Database is a container for data (document, message, web page), design elements (form, page, view, folder, navigator, agent, frameset, outline).

Two components in Domino server architecture.  There is an HTTP Server and a Domino Engine (URL Parser, Command Handler, and Database).

Web Access Syntax

  • http://host/data/base/NotesObject?Action&Arguments
  • Database = Notes Database
  • NotesObject  = the web accessible design element
  • Action = the action on NotesObject
  • Arguments = the qualifiers for the action (optional)

Notes Database Access Control List (ACL)

  • Define users and groups access privileges on the database
  • Seven access levels (manager, designer, editor, author, reader, depositor, and no access)
  • Eight access options for each level (create/delete documents, create/delete folders/views, create/delete agents, create/delete public documents)
  • Anonymous and -Default-
  • Maximum internet and password access: only works for name-password authentication but not for certificate authentication.  A web user cannot get the access greater than the "Maximum" access even if the access explicitly given is higher
  • Further restriction can be done by conjunction with reader field, author field, and access list of documents for granular read and write access control

Notes Web Authentication

  • Anonymous user - who does not have Person documents in DOmino Directory (names.nsf)
  • Authentication occurs if anonymous access is disabled on server configuration document and Notes objects
  • Name-password authentication: user/pass are authenticated to Person document and internet password in Domino directory (names.nsf).  Basic authentication and session-based authentication.  Internet password lockout function (Notes 8 only)
  • SSL client certificate authentication

Common Security Mistakes in Development

  1. Unauthorized Access: Anonymous access.  Anonymous privilege is assigned to Default access level if there is no anonymous group explicitly set.  Default access level is Designer and Maximum Internet and Password Access is Editor of most built-in templates.  Forceful browsing.  Solutions are to setup anonymous group and assign it "no access".  Review the ACLs of all databases and confidential documents.
  2. Using Default Objects (Databases):  Default databases are statrep.nsf, schema.nsf, reports.nsf, names.nsf, log.nsf, events.nsf, doladmin.nsf, dbdirman.nsf certsrv.nsf, certlog.nsf, admin4.nsf, ...  Anonymous users should not be allowed to access these databases.
  3. Default Objects (view): $DefautlView?OpenView, $DefaultNav?OpenNav, $DefaultForm?OpenForm, help?OpenHelp, $about?OpenAbout, $searchform?searchdomain, $searchform?searchsite, $searchform?searchview, $Icon?OpenIcon, $first, $file.  Solutions are to use the URL redirection and mapping on server document, customize the default pages, and apply the appropriate access control.
  4. SQL Injection: Places to process User Input (@Commands, WebQueryOpen, WebQuerySave, WebQueryClose, @URLQueryString, OpenAgent, RunAgent).  Solutions is input validation in fields by formula or lotus scripts
  5. Cross Site Scripting: Most cross site scripting vulnerabilities are persistent.  Solutions are to use input validaton or to HTMLencode.
  6. Session Management: By default uses basic authentication.  Username and password are sent in clear-text in teh packet of every request.  Solution is to configure the server document to use session-based authentication.  Do not append sensitive data to Querystring.
  7. Information Leakage: Hard coding username and password.  Solutions are to remove the sensitive information from the source code and log and customize the error message.
  8. Operating System Interaction: LotusScript has system commands such as Shell, OSLoadProgram, OSLoadLibrary, FileCopy, Open, Kill, Get, Input, Close.  Solution is to hardcode the path and validate the filename input.

Testing security is challenging but it can be done:

  • Lotus Notes Designer (Design Synopsis)
  • Grep
  • A good text editor
  • Paros

References

  • Secure Domino Application
  • Lotus Security Handbook