Friday, August 26, 2016

ZAP (OWASP Zed Attack Project) Basics

ZAP Overview

OWASP Zed Attack Proxy Project (ZAP) is a popular Java-based and open source security tools. It is useful for performing penetration tests on your (or ones you have permission to test) web site for security vulnerabilities.

It works similar to Fiddler, but has several tools for helping to find the vulnerabilities, not just give you the ability to hack at requests. It does this by having you change the proxy in your browser to point to ZAP and then point ZAP to your corporate proxy or the web site itself.

It is extensible via a plug-in architecture. There are lots of videos and tutorials on how to use ZAP. For more details there is an excellent ZAP Getting Started Guide that you can use to get everything installed and explains how to start using it.

Another great resource is: Getting Started with ZAP and the OWASP Top 10: Common Questions

Manual Tests

It is important to keep in mind that not all kinds of penetration / security checks can be done automatically and ZAP does not cover them. It is probably worth reviewing the information on the OWASP .NET Project for .NET security specifics.


Installing ZAP

On the home page for ZAP there Download ZAP link, but you can also use this direct download link to the page.

Monday, August 22, 2016

OpenXava

OpenXava is a nice Java based model driven development model such that you only have to create the domain classes you want to model. You then decorate the properties to add additional details such as relationships, if it is required, specify views, etc. The UI and database is generated automatically for you. This could be a very nice tool to do a quick POC or demo. It is open source that uses Eclipse as the IDE. It could be a good replacement for projects that used IronSpeed Designer and don't mind switching from C# to Java.

Wednesday, July 20, 2016

Customizing Code Coverage in VS2015

The code coverage in Visual Studio 2015 by default includes the test code itself. This is often not desired. Below are some links go pages to help with this.

Customizing Code Coverage Analysis
Using Code Coverage to Determine How Much Code is being Tested
Troubleshooting Code Coverage
Troubleshooting missing data in Code Coverage Results

My conclusion is that the default settings that comes Visual Studio 2015 is not sufficient because it includes the test code in the test results. I found the .runsettings file to be a necessary change. When I did this, I was tempted to exclude test assemblies to the list of modules to exclude, but found this actually stopped the tests from being reported on. Instead I found it better to use namespace exclusions using the function tags.

For example,

   <Functions>
              <Exclude>
                <!--Exclude (Tests from the results) any functions in namespaces that have Test in them-->
                <Function>.*Test.*</Function>

I also found it useful to exclude tests (classes or methods) from the code coverage results that use particular attributes on them. For example,

 <Attributes>
              <Exclude>
                <!--Don't forget "Attribute" at the end of the name -->
                
                                <Attribute>^Microsoft\.VisualStudio\.TestTools\.UnitTesting\.TestClassAttribute$</Attribute>
                <Attribute>^TechTalk\.SpecFlow\.GivenAttribute$</Attribute>
                <Attribute>^TechTalk\.SpecFlow\.WhenAttribute$</Attribute>
                <Attribute>^TechTalk\.SpecFlow\.ThenAttribute$</Attribute>


I did however add any assemblies that have their own unit tests and code coverage reports to the list of modules to exclude. That way the code coverage of these assemblies is not counted twice.

The rest of the .runsettings file can be just as the sample file from MS.
Also, Here is a reporting tool that helps show code coverage results in a more user friendly manner.

Monday, June 20, 2016

Links for Powershell

Microsoft Team Foundation Server Client - Nuget package to integrate with TFS (version control, work item tracking, build, etc via REST APIs

Get Started with the REST APIs - shows the url format, usage, etc for TFS REST APIs.

TFS API Part 33 - Get Build Definitions and Build Details - example of how to get Build definition details.

Creating a Build Definition using the TFS 2013 API - actually in C#, but should work for Powershell also.

Pester - PowerShell testing. Support in VS2015 now.

NuGet Links

NuGet Package Restore - tells how to configure NuGet, TFS, etc to support different NuGet restore models.

Migrating MSBuild-Integrated solutions to use Automatic Package Restore

New-NuGetPackage Powershell script - create and publish NuGet packaes using a .nuspec or project file from Explorer or Powershell.

NuGet Package To Automatically Create Your NuGet Packages

TFS 2015 Build: NuGet restore from an internal repository

Friday, April 22, 2016

How to have TFS version control not ignore .DLL and .EXE in the packages directory.

If you are not using Visual Studio to refresh your Nuget packages then you need to check them in to source control. In my case this is the version control in TFS. To solve the problem you just need to add a .tfignore file to the packages directory.

The easiest way to do this is to create a new .txt file in the packages directory and call it ".tfignore.". Notice it starts and ends with the period. The last period will be removed automatically and you will be left with a file called ".tfignore".

You can also use notepad.exe to create the file. The trick with this is to change the type to All File and just type the name ".tfignore".

Once you have a file created open it in notepad and add the following lines to it.

!*.exe
!*.dll

The ! tell the source control to NOT ignore the files with these extension.


TFS 2015 Build Highlights

Goals of new system
  • Web based
  • Simple customization
  • Real-time output
  • Versioning of build definition
  • Build pools - share build agents across projects and collections
  • Cross-platform - even Mac and Linux
  • Full support for XAML-based builds
Build Overview
  • Templates
  • Web Applications
  • Unit Testing
  • Staging and drop locations
  • Azure Deployment
  • Powershell

Build Definitions
  • Web based
  • Several Templates 
  • No XAML templates, but still supports them
  • My Dev Machine produces the same outputs as TFS will
  • Task gallery
  • Auditing (changes are logged with notes if desired).
  • Web based diff tool.
Running a Build
  • Real-time log view
  • Project by project breakdown
  • Build Outputs
Build Customization
  • Settings
  • Variables
  • Triggers
  • Versioning of build
  • Draft (not published yet)
  • Templates - reuse
Hosted Agent
  • Visual Studio Online (not on premise)
  • One build at a time (No XAM L Builds)
  • < 1 hr
  • < 10 GB storage
  • No admin rights
  • Can't log on
  • Run on Visual Studio Online, not your agent
  • No interactive mode

Configuration
  • Options
  • Multi-configuration
  • Staging & build drop
  • Templates
Deployment
  • Deployment templates
  • Azure
  • PowerShell