- Overview
- Forking the Repository
- Building the Application
- Running the Application
- Application Security Testing Integrations
- SAST using Fortify SCA command line
- SAST using Fortify ScanCentral SAST
- SAST using Fortify on Demand
- DAST using Fortify WebInspect
- DAST using Fortify ScanCentral DAST
- DAST using Fortify on Demand
- API Security Testing using Fortify WebInspect and Postman
- API Security Testing using ScanCentral DAST
- API Security Testing using Fortify on Demand
- FAST Using ScanCentral DAST and FAST proxy
- Build and Pipeline Integrations
- Developing and Contributing
- Licensing
For an "official" version of this application with additional pipeline integrations please visit https://github.com/fortify/IWA-Java.
IWA (Insecure Web App) Pharmacy Direct is an example Java/Spring Web Application for use in DevSecOps scenarios and demonstrations. It includes some examples of bad and insecure code - which can be found using static and dynamic application security testing tools such as those provided by Micro Focus Fortify.
One of the main aims of this project is to illustrate how security can be embedded early ("Shift-Left") and continuously ("CI/CD") in the development lifecycle. Therefore, a number of examples of "integrations" to common CI/CD pipeline tools are provided.
The application is intended to provide the functionality of a typical "online pharmacy", including purchasing Products (medication) and requesting Services (prescriptions, health checks etc). It has a modern-ish HTML front end (with some JavaScript) and a Swagger based API.
Please note: the application should not be used in a production environment!
An up-to-date version of the running application can be found at https://iwa.onfortify.com.
In order to execute example scenarios for yourself, it is recommended that you "fork" a copy of this repository into your own GitHub account. The process of "forking" is described in detail in the GitHub documentation - you can start the process by clicking on the "Fork" button at the top right.
In order to successfully build and run the application you will need to have Java JDK 11 installed and on your path.
To build the application using Gradle, execute the following from the command line:
.\gradlew clean build
There are a number of ways of running the application depending on the scenario(s) that you wish to execute.
To run (and test) locally in development mode, execute the following from the command line:
.\gradlew bootRun
Then navigate to the URL: http://localhost:8888. You can carry out a number of actions unauthenticated, but if you want to login you can do so as the following :
- user1/password
There is also an administrative user:
- admin/password
Note if you login with user2
, you will be subsequently asked for a Multi-Factor Authentication (MFA) code. You
can find this code by examining the console output.
If you would like to use a development email server, I would recommend using (smtp4dev)[https://github.com/rnwood/smtp4dev.git]. The easiest approach is to start it as a docker container:
docker run --rm -it -p 5000:80 -p 2525:25 rnwood/smtp4dev
Remove --rm -it
if you want to leave smtp4dev running in the background, otherwise it will run until you hit CTRL+C.
The (application-dev.yml)[./src/main/resources/application-dev.yml] file is already pre-configured to use this configuration.
Browse to http://localhost:5000
to see the emails.
The JAR file can be built into a Docker image using the provided Dockerfile
and the
following commands:
docker build -t iwa -f Dockerfile .
or on Windows:
docker build -t iwa -f Dockerfile.win .
This image can then be executed using the following commands:
docker run -d -p 8888:8888 iwa
There is also an example docker-compose.yml
file that illustrates how to run the application with HTTPS/SSL using
nginx and certbot - please note this is for reference only as it
uses a "hard-coded" domain name.
Most of the following examples need environment and user specific credentials. These are loaded from a file called .env
in the project root directory. This file is not created by default (and should never be stored in source control). An example
with all of the possible settings for the following scenarios is illustrated below:
# Application URL (locally)
APP_URL=http://localhost:8888
# Software Security Center
SSC_URL=http://[YOUR-SSC-SERVER]
SSC_USERNAME=admin
SSC_PASSWORD=password
SSC_AUTH_TOKEN=XXX
SSC_APP_NAME=IWA-Java
SSC_APP_VER_NAME=main
# ScanCentral SAST/DAST
SCANCENTRAL_CTRL_URL=http://[YOUR-SCANCENTRAL-SERVER]/scancentral-ctrl
SCANCENTRAL_CTRL_TOKEN=XXX
SCANCENTRAL_POOL_ID=00000000-0000-0000-0000-000000000002
[email protected]
SCANCENTRAL_DAST_API=http://[YOUR-SCANCENTRAL-DAST-SERVER]/api/
# ScanCentral FAST
FAST_EXE=C:\\Program Files\\Micro Focus WIRC Server\\Fast.exe
FAST_PORT=8087
FAST_PROXY=127.0.0.1:8087
# Fortify on Demand
FOD_API_URL=https://api.ams.fortify.com
FOD_API_KEY=XXXX
FOD_API_SECRET=YYYY
FOD_TENANT=[YOUR-TENANT]
FOD_USER=[YOUR-USERNAME]
FOD_PAT=XXXX
There is an example PowerShell script fortify-sast.ps1 that you can use to execute static application security testing via Fortify SCA.
.\bin\fortify-sast.ps1 -SkipSSC
This script runs a sourceanalyzer
translation and scan on the project's source code. It creates a Fortify Project Results file called IWA-Java.fpr
which you can open using the Fortify auditworkbench
tool:
auditworkbench.cmd .\IWA-Java.fpr
It also creates a PDF report called IWA-Java.pdf
and optionally
uploads the results to Fortify Software Security Center (SSC).
In order to upload to SSC you will need to have entries in the .env
similar to the following:
SSC_URL=http://localhost:8080/ssc
SSC_AUTH_TOKEN=28145aad-c40d-426d-942b-f6d6aec9c56f
SSC_APP_NAME=IWA-Java
SSC_APP_VER_NAME=main
The SSC_AUTH_TOKEN
entry should be set to the value of a 'CIToken' created in SSC "Administration->Token Management".
There is a PowerShell script fortify-scancentral-sast.ps1 that you can use to package up the project and initiate a remote scan using Fortify ScanCentral SAST:
.\bin\fortify-scancentral-sast.ps1
In order to use ScanCentral SAST you will need to have entries in the .env
similar to the following:
SSC_URL=http://localhost:8080/ssc
SSC_AUTH_TOKEN=6b16aa46-35d7-4ea6-98c1-8b780851fb37
SSC_APP_NAME=IWA-Java
SSC_APP_VER_NAME=main
SCANCENTRAL_CTRL_URL=http://localhost:8080/scancentral-ctrl
SCANCENTRAL_CTRL_TOKEN=96846342-1349-4e36-b94f-11ed96b9a1e3
SCANCENTRAL_POOL_ID=00000000-0000-0000-0000-000000000002
[email protected]
The SSC_AUTH_TOKEN
entry should be set to the value of a 'CIToken' created in SSC "Administration->Token Management".
To execute a Fortify on Demand SAST scan
you need to package and upload the source code to Fortify on Demand. To package the code into a Zip file for uploading
you can use the scancentral
command utility as following:
scancentral package -bt gradle -bf build.gradle -bt "clean build -x test" --output fod.zip
You can then upload this manually using the Fortify on Demand UI, using the FoDUploader utility or via the Fortify CLI using the following commands:
fcli fod session login --url http://api.ams.fortify.com -t YOUR_FOD_TENANT -u YOUR_USERNAME -p YOUR_PASSWORD
fcli fod sast-scan start --release YOUR_APP:YOUR_RELEASE -f fod.zip --store curScan
fcli fod sast-scan wait-for ::curScan::
To carry out a WebInspect scan you should first "run" the application using one of the steps described above. Then you can start a scan using the following command line:
"C:\Program Files\Fortify\Fortify WebInspect\WI.exe" -s ".\etc\IWA-UI-Dev-Settings.xml" -macro ".\etc\IWA-UI-Dev-Login.webmacro" -u "http://localhost:8888" -ep ".\IWA-DAST.fpr" -ps 1008
This will start a scan using the Default Settings and Login Macro files provided in the etc
directory. It assumes
the application is running on "localhost:8888". It will run a "Critical and High Priority" scan using the policy with id 1008.
Once completed you can open the WebInspect "Desktop Client" and navigate to the scan created for this execution. An FPR file
called IWA-DAST.fpr
will also be available - you can open it with auditworkbench
(or generate a
PDF report from using ReportGenerator
). You could also upload it to Fortify SSC or Fortify on Demand.
There is an example PowerShell script file fortify-webinspect.ps1 that you can run to execute the scan and upload the results to SSC:
.\bin\fortify-webinspect.ps1
You can invoke a Fortify on Demand dynamic scan using the FCLI utility. For example:
fcli sc-dast session login --ssc-url http://YOUR_SSC.DOMAIN -t YOUR_SSC_CI_TOKEN
fcli sc-dast scan -n "IWA-Java - FCLI" -s YOUR_SCAN_SETTINGS_ID --store curScan
fcli sc-dast scan wait-for ::curScan::
Fortify on Demands provides two means of carrying out DAST scanning: traditional DAST and DAST Automated. In this section we will using DAST Automated as this is more suitable of command and pipeline integration.
You can invoke a Fortify on Demand DAST Automated scan using the FCLI utility. For example:
fcli fod session login --url http://api.ams.fortify.com -t YOUR_FOD_TENANT -u YOUR_USERNAME -p YOUR_PASSWORD
fcli fod dast-scan start --release YOUR_APP:YOUR_RELEASE --store curScan
fcli fod dast-scan wait-for ::curScan::
TBD: how to upload login macros and/or workflows.
The IWA application includes a fully documented Swagger based API which you can browse to at http://localhost:8888/swagger-ui/index.html?configUrl=/v3/api-docs/swagger-config. You can carry out security testing of this API using Fortify WebInspect or ScanCentral DAST. A Postman collection is provided to help in this. You can exercise the collection using newman. For example from a PowerShell command prompt on Windows:
newman run .\etc\IWA-API-Dev-Auth.postman_collection.json --environment .\etc\IWA-API-Dev.postman_environment.json --export-environment .\etc\IWA-API-Dev.postman_environment.json
newman run .\etc\IWA-API-Dev-Workflow.postman_collection.json --environment .\etc\IWA-API-Dev.postman_environment.json
In order to use this collection with WebInspect you will need to make sure newman is on the path and then you can run:
& "C:\Program Files\Fortify\Fortify WebInspect\WI.exe" -pwc .\etc\IWA-API-Workflow.postman_collection.json -pec .\etc\IWA-API-Dev.postman_environment.json -ep ".\IWA-API.fpr"
Import the following Postman collections into ScanCentral DAST:
etc\IWA-API-Prod.postman_environment.json
- as Environmentetc\IWA-API-Auth.postman_collection.json
- as Authentication Collectionetc\IWA-API-Workflow.postman_collection.json
- as Workflow collection
You will then need the following settings for the Dynamic Token Generation
Response Token:
"accessToken"\s*:\s*"(?<BearerTokenValue>[-a-zA-Z0-9._~+/]+?=*)"
Request Token:
Authorization:\sBearer\s(?<BearerTokenValue>[^\r\n]*)\r?\n
Logout Condition:
[STATUSCODE]401
The scan can be run from the ScanCentral DAST UI or via saving the settings and using the fcli sc-dast scan
command.
An API scan can be carried out using the following "combined" Postman collection:
etc\IWA-API-Prod-Combined.postman_environment.json
This can be used with either traditional DAST or DAST Automated.
The Fortify FAST Proxy allows you to capture traffic from an automated test run and then use the traffic
as a workflow for a ScanCentral DAST execution. In order to carry out the example here you will need
to have installed WebInspect locally WIRCServerSetup64-ProxyOnly.msi
which is available in the Dynamic_Addons.zip
of the
ScanCentral DAST installation media.
There are some example Selenium which can used can be used to execute a simple
functional test of the running application. There are also a couple of PowerShell scripts start_fast_proxy.ps1 and stop_fast_proxy.ps1 that can
be used to start/stop the FAST Proxy. In order to use these scripts you will need to have entries in the .env
file similar to the following:
APP_URL=http://localhost:8888
SSC_AUTH_TOKEN_BASE64=MmYyMTA5MzYtN2Q5Ny00NmM1LWI5NTUtYThkZWI2YmJlMDUy
SSCANCENTRAL_DAST_API=http://scancentral-dast-api.example.com/api/
SCANCENTRAL_DAST_CICD_IDENTIFIER=c3c3df60-de68-45b8-89c0-4c07b53392e7
FAST_PORT=8087
FAST_PROXY=127.0.0.1:8087
The SSC_AUTH_TOKEN_BASE64
is the (first) encoded token shown in SSC not the (second) decoded token.
Then carry out the following from the command line:
python -m pip install --upgrade pipenv wheel
pipenv shell
pipenv install --dev
Make sure the application is running and then execute the following in a terminal window:
.\bin\start_fast_proxy.ps1
Then in another terminal window execute the following:
pytest -v -s
And then finally:
.\bin\stop_fast_proxy.ps1
The FAST executable from the first terminal should terminate and then a scan execute in your ScanCentral DAST environment.
If you are using Jenkins, a comprehensive Jenkinsfile
is provided to automate all of the typical
steps of a typical DevSecOps Continuous Delivery (CD) process. The example makes use of Fortify ScanCentral SAST/DAST and
Sonatype Nexus IQ for Software Composition Analysis.
To make use of the Jenkinsfile
create a new Jenkins Pipeline Job and in the Pipeline
section select Pipeline script from SCM
and enter the details of a forked version of this GitHub repository.
The first run of the pipeline should be treated as a "setup" step as it will create some Job Parameters which you can then select to determine which features you want to enable in the pipeline.
You will need to have installed and configured the Fortify Jenkins plugins.
There is lots of documentation in the Jenkinsfile
itself so please examine it to see what else
you will need to do for a successful invocation.
This repository includes a number of GitHub Actions examples in the .github/workflows that automate the build of the application and scans the code using either Fortify on Demand or Fortify ScanCentral for SAST.
For integrations with other pipeline tools please see https://github.com/fortify/IWA-Java.
Please see the Contribution Guide for information on how to develop and contribute.
If you have any problems, please consult GitHub Issues to see if it has already been discussed.
This application is made available under the GNU General Public License V3