Tools for testing security of sites and services

SOAP UI (Free) (New Rest and Json support)
Send raw SOAP, XML, REST/JSON requests to services.

Soap Sonar (Free version available)
Offers a much better user experience than Soap UI.

PortSwigger (Free)
Send handcrafted HTTP requests + Proxy

Fiddler (Free)
Web Debugging Proxy

OpenSSL
Test supported SSL protocols.

Documenting Technical Design - Ideas Smorgasbord

I get asked a lot what Technical Design is, sometimes what it isn't, and what to include in a technical document. As always the answer is it depends.  It depends on your audience, their skill set and level, and the environment. 

Here's a few ideas that I have found work.  This isn't a comprehensive list that should always be included, again think about who your audience is and would they be interested (relevance) in this section.  Consider the analogy of building a car: The person who will use it doesn't care about the tensile strength of the second and fourth piston. They care about how to drive it, maybe maintaining it, and what to do when something abnormal happens. But remember it depends on the audience, the mechanic will want different information, but he still won't necessarily care about the technology used to build the piston.

Technical Design should consider the following topics/sections: (In no particular order).

Tech Design is not:

• A complete War And Peace of how every line works. (Tech Design should be as short as possible using as many diagrams as possible to avoid text).
• Sequence Diagrams based exactly on code or Class diagrams based exactly on code. (This will go stale too quickly and creates a maintenance nightmare)
• An install guide. 
• Xml Code Comments/SandCastle. 
• Any Documentation Generated from code. 
• An API Guide. 
• A Test Plan. 
• How-to-use / user guide (this should be a separate document).

A See Also Section.
    List links to other relevant or related information.
   
Overview Section.
    No more than two paragraphs.  This is for business or non-techies who just want to know something about how the system works and how it fits into
    the bigger picture with other systems. What is it used for? What problem does it solve?
   
System Context.
    A single diagram showing this system as a single box and the other systems it integrates into.
   
Main Sequences and Flows.
    This is the main or significant work flows thru the system.  Use Abstract high level sequence diagrams. Each line should not represent a class but
    a major component / library / namespace within the system. Do not get into class and object detail, it will get out of date too quickly.
   
Hosting and Deployment.
    List all different options on how to host in a production environment. Also state the recommended or preferred hosting model.  State why there are
    multiple models.  Use deployment diagrams not text.  Try to show one box per deployed application, not one box per library. Draw lines only where
    external calls are made between applications.  Add text to each line describing http/tcp, authentication, authorisation, json/soap etc.
    Could include details of configuration options and environment settings required, if necessary.  This is not a installation guide.
   
How to integrate.
    Link to a document (best to keep it separate as it will not be relevant to all readers and could be long) describing how a developer takes the
    system as a framework and uses it. How do they install it, use it, and what do they need to do, how long is this getting up and running process
    going to take.  Obviously only applies if the system is a framework for developers rather than for consumers.
   
Multi-Tenancy
    Is the system multi-tenanted. If so how have you acheived this, trade-offs made, limitations etc.  How many tenants can it handle, how few?
   
Concurrency
    Multi-threading? STA? UI Threading? ASP.Net async? Task Factory - how?
   
Code Organisation.
    How is the code organised and why.  Possibly code metrics too so another party can get a sense for the size and complexity of the application.
   
Service Contracts, Endpoints and Data Contracts
    Describe all inbound services and their contracts. Describe all outbound service calls, their purpose, when they happen.  Also define or link to a
    data dictionary that describes all SOAP / Json payloads and fields.
   
Diagnostic Logging, Monitoring and Auditing
    Database tables involved.  What logging framework? Links to configure it. Default config (debug/release builds). What is auditing vs logging.
    Why is auditing required.  Performance counters and definition.  Other standard recommended performance counters. How do the Ops team support
    the system? Monitor it? Can they tell when it is failing before it fails? Windows Event Log. Health / Support service endpoints that might be available.
    (Ping, heartbeat, health check services).
   
Resilience
    Estimated usage stats (year 1,2,3). Estimate db size, requests per second, tenants, 24 hour (or other time period) load patterns.
    Where are the fail points from a business perspective? Is 1000ms per request ok? 3000? 10,000ms? 2 hours to process the last item in a queue behind a
    large batch?
    Exceptions: Different scenarios - (db is down, external 3rd party service is down, one server in the farm is down, entry point service endpoint is down,
    validation issues with inbound service data, inflight data cannot be updated back to db after reading it, system crashes during processing - how to
    recover? etc)  General exception strategy within the app. Where are they logged or not.
   
Security
    What security is applied to all endpoints.  User security. Pen testing considerations. OWASP. STRIDE. Known security concerns to address and how they
    are addressed.
    Database.
    Trusted subsystem?
    Required infrastructure security.
    Deployment time required security config not covered by installer.
   
Configuration Options for Runtime System.
    Are there runtime settings applied immediately without restart? App.config only? Other config? How are server farms updated?
    All config options listed and described. Or links to other doc.
   
Database Schema
    Data Dictionary or link to
    Describe data access strategy - stored procs, ORM, both, etc

Backwards Compatibility
    Are the existing devices out there with a version of the application. Ie are you upgrading backend services and there are existing UI's out there?
    Forwards Compatibility: How will future versions be compatible with this?
    Are your service contracts / Json transmissions versioned adequately?
    Are you recommending to clients that the URL contain a version number?
   
Other important / architecturally significant items
    Queueing / ServiceBus / Asynchronous design
    Installation issues - not an install guide
    Availability (do you need a draining shutdown, how much down time can you get / need)
    Usability
    Accessibility

   
   

Get out of the way I'm trying to work

A great concise post by Ayende on the Corporate development environments.

Part 1

Part 2

Take aways:

1. Development teams need access to allocated discretionary budgets for the express purpose to remove impediments -
1. Lack of tools
2. Lack of specialised skills (contractors, coaches, trainers)
3. Access to immediate replacement of broken hardware
2. Its more damaging for the business in the long run to burn out staff and deliver substandard software on time than to deliver late.

Web.Config Security Guidelines

http://www.iis.net/configreference/system.webserver/security

http://www.petefreitag.com/item/741.cfm

<configuration>
   <system.webServer>

       <httpProtocol>

         <customHeaders>

           <remove name="X-Powered-By"/>

         </customHeaders>

       </httpProtocol> 

       <security>
         <requestFiltering>
            <!-- block /CFIDE -->
            <denyUrlSequences>
               <add sequence="/CFIDE"/>
            </denyUrlSequences>
            <!-- block all file extensions except cfm,js,css,html -->
            <fileExtensions allowUnlisted="false" applyToWebDAV="true">
               <add fileExtension=".aspx" allowed="true" />
               <add fileExtension=".svc" allowed="true" />
               <add fileExtension=".cfm" allowed="true" />
               <add fileExtension=".js" allowed="true" />
               <add fileExtension=".css" allowed="true" />
               <add fileExtension=".html" allowed="true" />
            </fileExtensions>
            <!-- hide configuration dir -->
            <hiddenSegments applyToWebDAV="true">
               <add segment="configuration" />
            </hiddenSegments>
            <!-- limit post size to 10mb, query string to 256 chars, url to 1024 chars -->
            <requestLimits maxQueryString="256" maxUrl="1024" maxAllowedContentLength="102400000" />
            <!-- only allow GET,POST verbs -->
            <verbs allowUnlisted="false" applyToWebDAV="true">
               <add verb="GET" allowed="true" />
               <add verb="POST" allowed="true" />
            </verbs>
         </requestFiltering>
      </security>
   </system.webServer>
</configuration>

Or it could be scoped to a section of the web application.

<location path="Contoso">
   <system.webServer>
      <security>
         <authentication>
            <windowsAuthentication enabled="true" />
            <basicAuthentication enabled="false" />
            <anonymousAuthentication enabled="false" />
         </authentication>
         <access sslFlags="Ssl, SslNegotiateCert, Ssl128" />
         <requestFiltering>
            <fileExtensions>
               <add fileExtension=".inc" allowed="false" />
            </fileExtensions>
            <denyUrlSequences>
               <add sequence="_vti_bin" />
               <add sequence="_vti_cnf" />
               <add sequence="_vti_pvt" />
            </denyUrlSequences>
         </requestFiltering>
      </security>
   </system.webServer>
</location>

Additionally, also consider:

1. Applying an Http Module to remove the header "Server" as this cannot be removed by a web.config.
2. Applying an Http Module to ensure that ASP.Net does not throw an error on a custom Asp.Net error page, if it does it may disclose sensitive information.  It is cleaner to write another Http Module to catch these kind of errors and show a standard error page.
3. Also consider prefering later versions of TLS if available. TLS 1.2 will not automatically be used and is configured off by default in windows server 2008.  See here.
4. Encrypt viewstate.
5. Don't ever use session id in the Url.
6. Rescope any cookies (always prefer session cookies if possible) to your site only.
7. Preferably allow only one user session at a time.  If the same user attempts to access the site twice, alert them, or worst case revoke their session.