8.2 Creating GET and POST Workflow Actions

8.2 Creating GET and POST Workflow Actions

Quick Summary: Link-based workflow actions connect Splunk events to external web applications using HTTP protocols. HTTP GET actions append event field values into URL query strings to open threat intelligence lookups, IP WHOIS records, or internal CMDB pages. HTTP POST actions submit structured payload data within the HTTP request body (link.postargs) to trigger remote REST APIs, log incident tickets in ServiceNow or Jira, or activate SOAR playbooks. Both support target window controls (blank vs. self) and automatic URL encoding of field token variables.

---

1. Architectural Overview of Link-Based Workflow Actions

In enterprise operations, Splunk is the central nervous system for monitoring and analytics, but remediation, threat analysis, and ticketing occur in specialized external platforms. Link-based workflow actions create friction-free bridges between Splunk and these external ecosystems.

+------------------------------------------------------------------------------------------------+
|                       HTTP GET VS. HTTP POST WORKFLOW ACTION ARCHITECTURE                      |
|                                                                                                |
|  1. HTTP GET WORKFLOW ACTION (Read-Only / Idempotent Query):                                   |
|     User clicks "Lookup VirusTotal" on clientip=198.51.100.42                                  |
|     --> Browser constructs: https://www.virustotal.com/gui/ip-address/198.51.100.42/detection   |
|     --> Opens in New Tab (link.target = blank); parameters exposed in URL; safe for repeated execution.     |
|                                                                                                |
|  2. HTTP POST WORKFLOW ACTION (State-Changing / Payload Submission):                           |
|     User clicks "Create ServiceNow Incident" on host=web01, error=500                          |
|     --> Browser/Splunk sends HTTP POST to: https://instance.service-now.com/api/now/incident   |
|     --> HTTP Body Payload: { "caller": "splunk", "cmdb_ci": "web01", "urgency": "2" }     |
|     --> Ticket is created; parameters hidden from URL bar; modifies remote system state.       |
+------------------------------------------------------------------------------------------------+

Comparison: GET vs. POST Workflow Actions

---

2. Configuring HTTP GET Workflow Actions

GET workflow actions are designed for fast external reference lookups. When an analyst clicks a GET action, Splunk takes the template URL defined in link.uri, substitutes all $token$ placeholders with real event values, URL-encodes special characters in those values, and instructs the browser to navigate to that URL.

Configuration Attributes for GET Actions

Step-by-Step GET Action Walkthrough: External Threat Intelligence

Scenario: Threat Intel IP Lookup on VirusTotal & Cisco Talos

A Security Operations Center (SOC) wants tier-1 analysts to immediately check any suspicious external IP address (src_ip, dest_ip, or clientip) against VirusTotal and Cisco Talos with a single click.

Web UI Setup:

1. Navigate to Settings > Fields > Workflow actions.
2. Click New Workflow Action.
3. Enter the following parameters:
   • Destination app: search
   • Name: virustotal_ip_lookup
   • Label: VirusTotal Reputation: $@field_value$
   • Apply only to the following: Leave blank (applies across all sourcetypes).
   • Show action in: Field menu
   • Fields: src_ip, dest_ip, clientip, remote_ip
   • Action type: link
   • URI: https://www.virustotal.com/gui/ip-address/$@field_value$/detection
   • Method: GET
   • Open in: New window (writes link.target = blank)
4. Click Save.
5. Under Permissions, share the object globally or to the Search app.

Equivalent workflow_actions.conf Definition:

# $SPLUNK_HOME/etc/apps/search/local/workflow_actions.conf

[virustotal_ip_lookup]
type = link
link.method = get
label = VirusTotal Reputation: $@field_value$
display_location = field_menu
fields = src_ip, dest_ip, clientip, remote_ip
link.uri = https://www.virustotal.com/gui/ip-address/$@field_value$/detection
link.target = blank

[talos_ip_lookup]
type = link
link.method = get
label = Cisco Talos Lookup for $@field_value$
display_location = field_menu
fields = src_ip, dest_ip, clientip, remote_ip
link.uri = https://talosintelligence.com/reputation_center/lookup?search=$@field_value$
link.target = blank

---

3. Configuring HTTP POST Workflow Actions

POST workflow actions submit structured data to web endpoints. Unlike GET actions where parameters reside in the URL, POST actions package arguments into the HTTP request body. In workflow_actions.conf, each body parameter is defined using the prefix link.postargs.<n>.key and link.postargs.<n>.value.

+------------------------------------------------------------------------------------------------+
|                                 HTTP POST PAYLOAD CONSTRUCTION                                 |
|                                                                                                |
|  Event: host="db-srv01.corp" status="500" user="svc_batch" error_msg="DB Connection Timeout"   |
|                                                                                                |
|  Configuration:                                                                                |
|  link.uri = https://jira.company.com/rest/api/2/issue                                          |
|  link.postargs.1.key = project                                                                 |
|  link.postargs.1.value = SEC                                                                   |
|  link.postargs.2.key = summary                                                                 |
|  link.postargs.2.value = Splunk Alert: Critical error on $host$                                |
|  link.postargs.3.key = description                                                             |
|  link.postargs.3.value = User $user$ failed with: $error_msg$ in event $_raw$                  |
|  link.postargs.4.key = priority                                                                |
|  link.postargs.4.value = High                                                                  |
|                                                                                                |
|  Constructed HTTP Request:                                                                     |
|  POST /rest/api/2/issue HTTP/1.1                                                               |
|  Host: jira.company.com                                                                        |
|  Content-Type: application/x-www-form-urlencoded                                               |
|                                                                                                |
|  project=SEC&summary=Splunk+Alert%3A+Critical+error+on+db-srv01.corp&...                       |
+------------------------------------------------------------------------------------------------+

Step-by-Step POST Action Walkthrough: ServiceNow Incident Creation

Web UI Setup:

1. Navigate to Settings > Fields > Workflow actions.
2. Click New Workflow Action.
3. Configure fields:
   • Name: create_servicenow_incident
   • Label: Create ServiceNow Incident ($host$)
   • Apply only to the following sourcetype: access_combined
   • Show action in: Event menu
   • Action type: link
   • URI: https://mycorp.service-now.com/nav_to.do?uri=incident.do
   • Method: POST
   • Post arguments:
     • sysparm_query: caller_id=Splunk^short_description=Web server $host$ error $status$^description=Raw Event: $_raw$
   • Open in: New window (writes link.target = blank)
4. Click Save.

Equivalent workflow_actions.conf Definition:

# $SPLUNK_HOME/etc/apps/search/local/workflow_actions.conf

[create_servicenow_incident]
type = link
link.method = post
label = Create ServiceNow Incident ($host$)
display_location = event_menu
sourcetype = access_combined
link.uri = https://mycorp.service-now.com/incident.do
link.target = blank
link.postargs.1.key = sysparm_query
link.postargs.1.value = caller_id=Splunk^short_description=Web server $host$ error $status$^description=Raw Event: $_raw$
link.postargs.2.key = category
link.postargs.2.value = Infrastructure
link.postargs.3.key = impact
link.postargs.3.value = 2
link.postargs.4.key = urgency
link.postargs.4.value = 1

---

4. Target Window Controls & Navigation Behavior

The link.target configuration controls how the user's browser renders the target destination when a link-based action is triggered:

                                 ┌───────────────────────────────┐
                                 │   Target Window Options       │
                                 └──────────────┬────────────────┘
                                                │
                       ┌────────────────────────┴────────────────────────┐
                       ▼                                                 ▼
         ┌───────────────────────────┐                     ┌───────────────────────────┐
         │     link.target = blank  │                     │    link.target = self    │
         │       (New Tab/Window)    │                     │     (Current Window)      │
         ├───────────────────────────┤                     ├───────────────────────────┤
         │ • Default setting         │                     │ • Overwrites active tab   │
         │ • Preserves Splunk search │                     │ • Loses search state      │
         │ • Ideal for external tools│                     │ • Used for intranet apps  │
         └───────────────────────────┘                     └───────────────────────────┘

---

5. URL Encoding, Special Characters & Token Escaping

When passing dynamic data into external web links, character formatting and encoding require careful consideration:

1. Automatic Dynamic URL Encoding

Splunk automatically applies standard RFC 3986 percent-encoding to all field values substituted into $fieldname$ tokens within link.uri and link.postargs.

• Spaces are encoded as %20 or +
• Slashes (/), ampersands (&), and question marks (?) within the field value are encoded so they do not break the URL structure.

2. Static URI Formatting

Static characters explicitly authored in the link.uri string itself are not escaped. You must write proper URL syntax with standard query delimiters:

# Correct syntax: static '?' and '&' separate query arguments
link.uri = https://search.internal.corp/query?host=$host$&app=$app_name$

3. Escaping Literal Dollar Signs

If an external service requires a literal dollar sign in a query string or argument (or if a label text contains currency), escape it with a double dollar sign ($$):

# Displays label as: "Check Pricing ($ USD) for Server $host$"
label = Check Pricing ($$ USD) for Server $host$

---

6. Enterprise Security & Governance for External Actions

Power Users and administrators must enforce strict security controls when designing external workflow actions:

1. Data Leakage in GET Query Strings: GET URLs are logged in plain text by web proxies, browser histories, and edge firewalls. Never configure GET workflow actions that pass sensitive data (passwords, social security numbers, API tokens, or session IDs) in URL query parameters. Always use HTTPS POST for sensitive attributes.
2. Destination Protocol Validation: Ensure all external workflow action URIs enforce encrypted HTTPS (https://) rather than unencrypted HTTP (http://) to protect data in transit.
3. Cross-Origin Resource Sharing (CORS) & Authentication: POST actions submitted via standard browser form posts depend on existing active sessions or API tokens accepted by the target endpoint. If an endpoint requires header-based OAuth tokens that cannot be supplied in form posts, consider Splunk alert webhooks or SOAR integrations instead.
4. Preventing Open Redirect Hazards: Ensure internal workflow action URIs point strictly to trusted, whitelisted enterprise domains to prevent malicious URI redirection attacks.