Jira
3 TopicsTraffic Shaping and Atlassian Jira
Hi All, I'm having an issue getting Traffic Shaping situated for Jira - here's what I need done: Sticky Sessions If the URI is rest - then go to Pool2 Else if that URI is rest/login.jsp - Pool1 All others go to Pool1 The problem I'm having, is it always routes me back to pool2 when HTTP_REQUEST { if { [string tolower [HTTP::uri]] contains "/rest" }{ pool pl-prd-jira.ftr.com2-tcp8080 } }Solved968Views0likes4CommentsAtlassian Jira Contact Administrator Server Side Template Injection (CVE-2019-11581)
Recently a Server Side Template Injection vulnerability was discovered in Atlassian Jira. The vulnerability allows attackers to achieve Remote Code Execution on unpatched Jira instances. Jira uses the Apache Velocity template engine in order to render various email notification templates that are sent to the users during the day to day work with the system. Velocity allows Java functions to be called and Java objects to be used alongside the standard HTML content that defines the email template. The vulnerability root cause is in Jira’s administrators contact form which allows users to report issues via email directly to the system administrators. This feature is disabled by default and can only be enabled when an SMTP server is configured in Jira. Figure 1: Jira Contact Administrator Form Figure 2: Jira Contact Administrator Velocity Template File Before Jira was patched the subject field of the form was directly inserted to the template as a string and was not escaped correctly by binding it into a Velocity variable. This allowed anyone who submits the form to inject valid Velocity code into the template which will later be interpreted once the template is rendered. Figure 3: Jira Contact Administrator unpatched Java code After the patch the Java code that binds the user input into the Velocity template was changed by creating an additional Velocity variable for the subject field. Figure 4: Jira Contact Administrator patched Java code Mitigating the vulnerability with BIG-IP ASM BIG-IP ASM customers under any supported BIG-IP version are already protected against this vulnerability, as the exploitation attempt will be detected by an existing Java code injection attack signature (200004174) which can be found in signature sets that include “Server Side Code Injection” attack type or “Java Servlets/JSP” System. In addition we will release an additional signature specific to this vulnerability in the upcoming ASM Security Update. Figure 5: Exploitation attempt blocked by signature id 200003437.943Views0likes0CommentsSimplifying API Security with New Jira Integration and F5 Distributed Cloud
Introduction APIs fuel modern applications—but as they scale, grow, and evolve, API sprawl becomes a serious concern for security and operations teams. That’s where F5 Distributed Cloud API Discovery comes into play: enabling deep visibility into all your APIs, whether managed or unmanaged. And now, with our new integration with Jira, API lifecycle management just got a whole lot easier. API Discovery - The foundation of API Security Before you can protect or govern your APIs, you need to know what exists. F5 Distributed Cloud API Discovery continuously scans your environments (including ingress gateways and services) to automatically detect, catalog, and classify APIs—including shadow APIs and zombie endpoints you may not even know exist. This forms the foundation for API Security, Governance, and Compliance. But discovering APIs is only the first step. You still need to triage findings, prioritize action, and loop in the right teams to fix or respond. Introducing Jira Ticketing Integration With the new Jira integration, customers can now seamlessly push API discovery security posture findings into their ticketing and workflow systems. This accelerates remediation, reducing silos, and enabling true DevSecOps collaboration. Key capabilities: Automatic ticket creation from F5 Distributed Cloud API Security to Jira’s ticketing system for the vulnerabilities discovered Detailed context embedded in Jira ticket - API endpoint, Base Path, API Category, Authentication status, vulnerability details, risk score and suggested remediation actions Assign to Teams based on API owner, service or environment This helps security and platform teams shift left while giving development teams better context to secure their APIs. Pre-requisites You need to have Jira Service Management (SaaS) tenant and account Distributed Cloud Tenant 1. Jira Service Management Account (SaaS) 2. Create a project (In this example: project name is "F5") 3. Generate API Token to allow F5 Distributed Cloud to communicate with Jira Make sure of the expiration date of this API token - API token should be valid for the communication between F5 Distributed Cloud and Jira 4. In F5 Distributed Cloud Tenant, Create new ticket tracking system object with Jira details (Shared Configuration Tile -> Manage -> Ticket Tracking System) It requires to fill "API Token", "Jira Account Email" and "Jira Organization Domain" 5. Under API Endpoint Dashboard, find the relevant API Endpoint you need to trigger Jira Ticket (API Endpoint -> Security Posture -> relevant API vulnerability -> Create Ticket) Ticket will be created automatically in Jira and then you can assign it to one of the team members. It could be service owner or API owner You can also review the ticket in F5 API Endpoint Security Posture with direct link to Jira ticket Summary Too often, API security tools operate in silos, separate from the developer and operations workflows. This integration bridges that gap, enabling: DevOps-friendly workflows Faster MTTR (mean time to remediation) Better cross-team visibility Automated compliance tracking By turning API discovery insights into actionable tasks, organizations can better manage risk and reduce operational overhead.153Views1like0Comments