OWASP Tactical Access Defense Series: Broken Function Level Authorization (BFLA)
Broken Function Level Authorization (BFLA) is a type of security vulnerability in web applications where an attacker can access functionality or perform actions they should not be authorized to perform. This problem happens when an application doesn’t check access control on functions or endpoints correctly. This lets users do things that are not allowed. In this article, we are going through API5 item from OWASP Top 10 API Security risks and exploring F5 BIG-IP Access Policy Manager (APM) as a role in our arsenal Let’s consider our test application for each retail agent to submit their sales data, but without the ability to retrieve any from the system. In HTTP terms, the retail agent can POST but not allowed to perform GET, while the manager can perform GET to check agents performance, and collected data. Mitigating Risks with BIG-IP APM BIG-IP APM per-request granularity: with per-request granularity, organizations can dynamically enforce access policies based on various factors such as user identity, device characteristics, and contextual information. This enables organizations to implement fine-grained access controls at the API level, mitigating the risks associated with Broken Function Level Authorization. Key Features: Dynamic Access Control Policies: BIG-IP APM empowers organizations to define dynamic access control policies that adapt to changing conditions in real-time. By evaluating each API request against these policies, BIG-IP APM ensures that authorized users can only perform specific authorized functions (actions) on specified resources. Granular Authorization Rules: BIG-IP APM enables organizations to define granular authorization rules that govern access to individual objects or resources within the API ecosystem. By enforcing strict permission checks at the object level, F5 BIG-IP APM prevents unauthorized functions. Related Content F5 BIG-IP Access Policy Manager | F5 Introduction to OWASP API Security Top 10 2023 OWASP Top 10 API Security Risks – 2023 - OWASP API Security Top 10 API Protection Concepts OWASP Tactical Access Defense Series: How BIG-IP APM Strengthens Defenses Against OWASP Top 10 OWASP Tactical Access Defense Series: Broken Object-Level Authorization and BIG-IP APM F5 Hybrid Security Architectures (Part 5 - F5 XC, BIG-IP APM, CIS, and NGINX Ingress Controller) OWASP Tactical Access Defense Series: Broken Authentication and BIG-IP APM OWASP Tactical Access Defense Series: Broken Object Property-Level Authorization and BIG-IP APM OWASP Tactical Access Defense Series: Unrestricted Resource ConsumptionAccess Troubleshooting: BIG-IP APM OIDC integration
Introduction Troubleshooting Access use cases can be challenging due to the interconnected components used to achieve such use cases. A simple example for Active Directory authentication can go through below challenges, DNS resolution of Domain Controller (DC) configured. Reachability between F5 and DC. Communication ports used. Domain account privileges. Looking at the issue of non-working Active Directory (AD) authentication is a complex task, yet looking at each component to verify the functionality is much easier and shows output the influence further troubleshooting actions. Implementation and troubleshooting We discussed the implementation of OpenID Connect over here Let's discuss here how we can troubleshoot issues in OIDC implementation, here's a summary of the main points we are checking Role Troubleshooting main points OAuth Authorization Server DNS resolution for the authentication destination. Routing setup to the authentication system. Authentication configurations and settings. Scope settings. Token signing and settings. OAuth Client DNS resolution for the authorization server. Routing setup. Token settings. Authorization attributes and parameters. OAuth Resource Server Token settings. Scope settings Looking at the main points, you can see the common areas we need to check while troubleshooting OAuth / OIDC solutions, below are the troubleshooting approach we are following, Check the logs. APM logging provides a comprehensive set of logs, the main logs to be checked apm, ltm and tmm. DNS resolution and check DNS resolver settings. Routing setup. Authentication methods settings. OAuth settings and parameters. Check the logs The logs are your true friends when it comes to troubleshooting. We start by creating debug logging profile Overview > Event logs > Setting. Select the target Access Policy to apply the debug profile. Case 1: Connection reset after authentication In this case the below is the connection sequence, User accessing through F5 acting as Client + RS. Users are redirected to OAuth provider for authentication. User is redirected back to F5 but connection resets at this point. Troubleshooting steps: Checking logs by clicking the session ID fromAccess > Overview. From the below logs we can see the logon was successful but somehow the Authorization code wasn’t detected. One main reason would be mismatched settings between Auth server and Client configurations. In our setup I’m using provider flow type as Hybrid and format code-idtoken. Local Time 2024-06-11 06:47:48 Log Message /Common/oidc_google_t1.app/oidc_google_t1:Common:204adb19: Session variable 'session.logon.last.result' set to '1' Partition Common Local Time 2024-06-11 06:47:49 Log Message /Common/oidc_google_t1.app/oidc_google_t1:Common:204adb19: Authorization code not found. Partition Common Checking back the configuration to validate the needed flow type: adjust flow type at the provider settings to beAuthorization Code instead of Hybrid. Case 2: Expired JWT Keys In this case the below is the connection sequence, User accessing through F5 acting as Client + RS. Users are redirected to OAuth provider for authentication. User is redirected back to F5 with Access denied. Troubleshooting steps: Checking logs by clicking the session ID from Access > Overview. From the below logs we can see the logon was successful but somehow the Authorization code wasn’t detected. One main reason can be the need to rediscover JWT keys. Local Time 2024-06-11 06:51:06 Log Message /Common/oidc_google_t1.app/oidc_google_t1:Common:848f0568: Session variable 'session.oauth.client.last.errMsg' set to 'None of the configured JWK keys match the received JWT token, JWT Header: eyJhbGciOiJSUzI1NiIsImtpZCI6ImMzYWJlNDEzYjIyNjhhZTk3NjQ1OGM4MmMxNTE3OTU0N2U5NzUyN2UiLCJ0eXAiOiJKV1QifQ' Partition Common The action to be taken would be to rediscover the JWT keys if they are automatic or add the new one manually. Head toAccess ›› Federation : OAuth Client / Resource Server : Provider Select the created provider. Click Discover to fetch new keys from provider Save and apply the new policies settings. Case 3: OAuth Client DNS resolver failure In this case the below is the connection sequence, User accessing through F5 acting as Client + RS. Users are redirected to OAuth provider for authentication. User is redirected back to F5 with Access denied. Troubleshooting steps: Checking logs by clicking the session ID fromAccess > Overview. From the below logs we can see the logon was successful but somehow the Authorization code wasn’t detected. Another reason for such behavior can be the DNS failure to reach to OAuth provider to validate JWT keys. Local Time 2024-06-12 19:36:12 Log Message /Common/oidc_google_t1.app/oidc_google_t1:Common:fb5d96bc: Session variable 'session.oauth.client.last.errMsg' set to 'HTTP error 503, DNS lookup failed' Partition Common Checking DNS resolver Network ›› DNS Resolvers : DNS Resolver List Validate resolver config. is correct. Check route to DNS server Network ›› Routes Note, DNS resolver uses TMM traffic routes not the management plane system routing. Case 4: Token Mismatch In this case the below is the connection sequence, User accessing through F5 acting as Client + RS. Users are redirected to OAuth provider for authentication. User is redirected back to F5 with Access denied. Troubleshooting steps: Checking logs by clicking the session ID fromAccess > Overview. We will find the logs showing Bearer token is received yet no token enabled at the client / resource server connections. Local Time 2024-06-21 07:25:12 Log Message /Common/f5_local_client_rs.app/f5_local_client_rs:Common:c224c941: Session variable 'session.oauth.client./Common/f5_local_client_rs.app/f5_local_client_rs_oauthServer_f5_local_provider.token_type' set to 'Bearer' Partition Common Local Time 2024-06-21 07:25:12 Log Message /Common/f5_local_client_rs.app/f5_local_client_rs:Common:c224c941: Session variable 'session.oauth.scope./Common/f5_local_client_rs.app/f5_local_client_rs_oauthServer_f5_local_provider.errMsg' set to 'Token is not active' Partition Common We need to make sure client and resource server have JWT token enabled instead of opaque and proper JWT token is selected. Case 5: Audience mismatch In this case the below is the connection sequence, User accessing through F5 acting as Client + RS. Users are redirected to OAuth provider for authentication. User is redirected back to F5 with Access denied. Troubleshooting steps: Checking logs by clicking the session ID fromAccess > Overview. We will find the logs stating incorrect or unmatched audience. Local Time 2024-06-23 21:32:42 Log Message /Common/f5_local_client_rs.app/f5_local_client_rs:Common:42ef6c51: Session variable 'session.oauth.scope.last.errMsg' set to 'Audience not found : Claim audience= f5local JWT_Config Audience=' Partition Common Case 6: Scope mismatch In this case the below is the connection sequence, User accessing through F5 acting as Client + RS. Users receive authorization error with wrong scope. Troubleshooting steps: Checking logs by clicking the session ID fromAccess > Overview. Scope name is mentioned in the logs, in this case I named it “wrongscope” You will see scope includes openid string, this is because we have openid enabled. Change the scope to the one configured at the provider side. Local Time 2024-06-24 06:20:28 Log Message /Common/oidc_google_t1.app/oidc_google_t1:Common:edacbe31:/Common/oidc_google_t1.app/oidc_google_t1_act_oauth_client_0_ag: OAuth: Request parameter 'scope=openid wrongscope' Partition Common Case 7: Incorrect JWT Signature In this case the below is the connection sequence, User accessing through F5 acting as Client + RS. Users are redirected to OAuth provider for authentication. User is redirected back to F5 with Access denied. Troubleshooting steps: Checking logs by clicking the session ID fromAccess > Overview. We will find the logs showing Bearer token is received yet no token enabled at the client / resource server connections. Local Time 2024-06-21 07:25:12 Log Message /Common/f5_local_client_rs.app/f5_local_client_rs:Common:c224c941: Session variable 'session.oauth.scope./Common/f5_local_client_rs.app/f5_local_client_rs_oauthServer_f5_local_provider.errMsg' set to 'Token is not active' Partition Common When trying to renew the JWT key we see this error in the GUI. An error occurred: Error in processing URL https://accounts.google.com/.well-known/openid-configuration. The message is - javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target We need at this step to validate the used CA bundle and if we need to allow the trust of expired or self-signed JWT tokens. General issues In addition to the listed cases above, we have some general issues: DNS failure at client side not able to reach whether the F5 virtual server or OAuth provider to provide authentication information. In this case, please verify DNS configurations and Network setup on the client machine. Validate HTTP / SSL / TCP profiles at the virtual server are correctly configured. Related Content DNS Resolver Overview BIG-IP APM deployments using OAuth/OIDC with Microsoft Azure AD may fail to authenticate OAuth and OpenID Connect - Made easy with Access Guided Configurations templates Request and validate OAuth / OIDC tokens with APM F5 APM OIDC with Azure Entra AD Configuring an OAuth setup using one BIG-IP APM system as an OAuth authorization server and another as the OAuth clientOWASP Tactical Access Defense Series: Unrestricted Resource Consumption
Unrestricted resource consumption occurs when an API does not adequately limit or control the consumption of its resources, such as CPU, memory, disk space, network bandwidth, or database connections. This lack of control can lead to resource exhaustion and denial of service (DoS) conditions. In this article, we are going through API4 item from OWASP top 10 API Security risks exploring F5 BIG-IP Access Policy Manager (APM) role in our arsenal. Identify Vulnerable APIs It's common to find APIs that do not limit client interactions or resource consumption. APIs can affect different backend endpoint resources: Control number of resources returned. Infer extra costs on service providers' business/pricing model. exhuast resources CPU, memory, disk space or network connections. Common examples of this vulnerability: Allowing excessively large payloads in requests. Permitting unbounded loops or deep recursion in API processing logic. Lack of rate limiting, which could allow attackers to overwhelm the API with too many requests. Insufficient control over the creation and management of server-side sessions. Out of the Shadows: API Discovery and Securitypresents an incredible way to secure APIs via F5 Distributed Cloud (F5 XC). In our article we focus on access capabilities, which can be highlighted here in rate limiting the requests associated with a specific user/machine. Mitigating Risks with BIG-IP APM BIG-IP APM per-request granularity. With per-request granularity, organizations can dynamically enforce access policies based on various factors such as user identity, device characteristics, and contextual information. This enables organizations to implement fine-grained access controls at the API level, mitigating the risks associated with Unrestricted Resources Consumption. Key Features: Dynamic Access Control Policies: BIG-IP APM empowers organizations to define dynamic access control policies that adapt to changing conditions in real-time. By evaluating each API request against these policies, BIG-IP APM ensures that only authorized users can access specific resources and perform permitted actions. Granular Authorization Rules: BIG-IP APM enables organizations to define granular authorization rules that govern access to individual objects or resources within the API ecosystem. By enforcing strict authorization checks at the object level, F5 APM prevents unauthorized users from tampering with sensitive data or performing unauthorized actions. Apply rate limiting to APIs based on initiator identity, which provides a great way to protect while maintaining the service for legitimate users. Related Content F5 BIG-IP Access Policy Manager | F5 Introduction to OWASP API Security Top 10 2023 OWASP Top 10 API Security Risks – 2023 - OWASP API Security Top 10 API Protection Concepts OWASP Tactical Access Defense Series: How BIG-IP APM Strengthens Defenses Against OWASP Top 10 OWASP Tactical Access Defense Series: Broken Object Level Authorization and BIG-IP APM F5 Hybrid Security Architectures (Part 5 - F5 XC, BIG-IP APM, CIS, and NGINX Ingress Controller) OWASP Tactical Access Defense Series: Broken Authentication and BIG-IP APM OWASP Tactical Access Defense Series: Broken Object Property Level Authorization and BIG-IP APMOWASP Tactical Access Defense Series: Broken Object Property Level Authorization and BIG-IP APM
AUTHOR NOTE: Unauthorized access to private/sensitive object properties may result in data disclosure, data loss, or data corruption. Under certain circumstances, unauthorized access to object properties can lead to privilege escalation or partial/full account takeover. In this article we are going through API3 item from OWASP top 10 API Security risks exploring BIG-IP Access Policy Manager (APM) role in our arsenal. Identifying Vulnerable APIs In order to identify the API endpoint is vulnerable to Broken Object Property Level Authorization, Sensitive properties exposure of certain object for non-intended user (Excessive Data Exposure). import requests # Assuming the API endpoint for retrieving user data is /api/users api_endpoint = "https://example.com/api/users" # Sending a GET request to the API endpoint response = requests.get(api_endpoint) # Checking if the request was successful (status code 200) if response.status_code == 200: # Printing the response content (which could contain excessive data) print(response.json()) else: print("Failed to retrieve data from the API") API allow to change, add or delete sensitive object property for non-intended user (Mass assignment). import requests # Assuming the API endpoint for updating user information is /api/users api_endpoint = "https://example.com/api/users" # Malicious payload containing additional fields malicious_payload = { "username": "malicious_user", "password": "password123", "isAdmin": True # Malicious user attempts to elevate privileges } # Sending a POST request with the malicious payload response = requests.post(api_endpoint, json=malicious_payload) # Checking if the request was successful (status code 200) if response.status_code == 200: print("User information updated successfully") else: print("Failed to update user information") Object Property Level Authorization involves controlling access to specific properties or attributes of an object within a system. Instead of granting blanket access to an entire object, this approach enables fine-grained control, allowing administrators to restrict or permit access to individual properties based on user roles or permissions. While implementing protection against such security risk involves different aspects, one is making sure the user is authorized to access object property, and here BIG-IP APM plays crucial role. Mitigating Risks with BIG-IP APM BIG-IP APM per-request granularity. With per-request granularity, organizations can dynamically enforce access policies based on various factors such as user identity, device characteristics, and contextual information. This enables organizations to implement fine-grained access controls at the API level, mitigating the risks associated with Broken Object Property Level Authorization. Key Features: Dynamic Access Control Policies: BIG-IP APM empowers organizations to define dynamic access control policies that adapt to changing conditions in real-time. By evaluating each API request against these policies, BIG-IP APM ensures that only authorized users can access specific resources and perform permitted actions. Granular Authorization Rules: BIG-IP APM enables organizations to define granular authorization rules that govern access to individual objects or resources within the API ecosystem. By enforcing strict authorization checks at the object level, F5 APM prevents unauthorized users from tampering with sensitive data or performing unauthorized actions. Conclusion In conclusion, BIG-IP APM per-request granularity is a powerful tool for defending against Broken Object-Level Authorization vulnerabilities in APIs. By enforcing fine-grained access controls at the API level, organizations can mitigate the risks associated with unauthorized access to sensitive data. Additionally, proactive security assessments and vulnerability scans are essential for identifying and addressing vulnerabilities in APIs, thereby strengthening overall security posture in the digital ecosystem. Related Content F5 BIG-IP Access Policy Manager | F5 Introduction to OWASP API Security Top 10 2023 OWASP Top 10 API Security Risks – 2023 - OWASP API Security Top 10 API Protection Concepts OWASP Tactical Access Defense Series: How BIG-IP APM Strengthens Defenses Against OWASP Top 10 OWASP Tactical Access Defense Series: Broken Object Level Authorization and BIG-IP APM F5 Hybrid Security Architectures (Part 5 - F5 XC, BIG-IP APM, CIS, and NGINX Ingress Controller) OWASP Tactical Access Defense Series: Broken Authentication and BIG-IP APMOWASP Tactical Access Defense Series: Broken Authentication and BIG-IP APM
The threat of broken authentication poses a significant risk to organizations, potentially leading to unauthorized access and data breaches. In the face of this formidable challenge, F5's Access Policy Manager (APM) emerges as a robust and indispensable solution. By seamlessly integrating advanced authentication mechanisms and comprehensive access controls, F5 BIG-IP APM stands as a stalwart guardian against the vulnerabilities associated with broken authentication. This article explores the pivotal role played by BIG-IP APM in fortifying authentication protocols, mitigating risks, and ensuring a resilient defense against unauthorized access, ultimately safeguarding the integrity and security of sensitive data in today's dynamic digital environment. Broken Authentication Broken Authentication Examples BIG-IP APM and Broken Authentication Related Content Broken Authentication Authentication mechanism is an exposed target due to the nature of this function, as authentication is the first point of entry to any platform. The difficulty to exploit authentication weaknesses differs based on how the authentication platform is secured. In the current digital era the security perimeters are very fluid, and so are the trust boundries for our authentication platforms those require more cautions from the developers and security architects regarding authentication flows. Not only we need to protect authentication endpoints and flows, but also some overlooked items like forget and reset password endpoints. How can we consider endpoint to be vulnerable? Credential stuffing. Brute force attacks targetting users' accounts. Weak Passwords. Sensitive details in the URL (passwords, Tokens). Allow users sensitive actions without confirmation. No validation for the tokens authenticity. Accept unsigned or weak jwt tokens. No validation for jwt expiration. Use of plain-text, non-encrypted or non-hashed passwords. Use of weak encryption algorithms. Endpoint can access each other without proper authentication. Use weak or predictable tokens for intra-endpoint authentication. Broken Authentication Examples Making use of GraphQL query patching to bypass API ratelimiting and brute force user's login. POST /graphql [ {"query":"mutation{login(username:\"victim\",password:\"password\"){token}}"}, {"query":"mutation{login(username:\"victim\",password:\"123456\"){token}}"}, {"query":"mutation{login(username:\"victim\",password:\"qwerty\"){token}}"}, ... {"query":"mutation{login(username:\"victim\",password:\"123\"){token}}"}, ] Update / modify user's sensitive information without API authorization token. PUT /account Authorization: Bearer <token> { "newpassword": "<new_password>" } BIG-IP APM and Broken Authentication We start with creating our Per-Request policy, this policy works in a different way than the per-session policy, as the flow will be evaluted on a per-request basis, making sure to consider variations throught the session life-time. Below are some of the key benefits: Wide range of Authentication, SSO, and MFA mechanisms to properly identify the initiating machine or user. Ability to integrate with 3rd parties to provide additional enforcement decisions based on the organization's policy. Ability to apply endpoint checks on the client side before session initiation. This goes to BIG-IP in general, the ability to apply custom traffic control on both of the traffic sides, Client and Server. The ability to create whitelist / blacklist for API Access tokens, JSON Web Tokens ID (JTI) or a different element based on the used authentication method, below example steps for JWT: Extract JTI value from Access token. Add JTI value to whether Allow/Block lists. Related Content F5 BIG-IP Access Policy Manager | F5 Introduction to OWASP API Security Top 10 2023 OWASP Top 10 API Security Risks – 2023 - OWASP API Security Top 10 API Protection Concepts OWASP Tactical Access Defense Series: How BIG-IP APM Strengthens Defenses Against OWASP Top 10 OWASP Tactical Access Defense Series: Broken Object Level Authorization and BIG-IP APM F5 Hybrid Security Architectures (Part 5 - F5 XC, BIG-IP APM, CIS, and NGINX Ingress Controller)Crafting Secure Paths: The Intricacies of VPN Solutions on BIG-IP APM
Introduction In this article we are exploring Virtual Private Networks (VPN) solutions on F5 BIG-IP Access Policy Manager (APM), In today's digital landscape, secure connectivity is paramount, and BIG-IP APM stands at the forefront, offering a diverse array of VPN options to suit various needs. In this article, we'll delve into the world of BIG-IP APM VPNs, from their different flavors to the tight integration with other modules that enrich the overall solution. Join us as we unravel the complexities, uncover the nuances, and discover how F5 Networks empowers organizations to craft robust, tailored VPN solutions for their unique requirements. BIG-IP APM VPN Solutions VPN is a mean to connect trusted sites over untrusted medium, a user to a corporate portal, branch to main office or between different data centeres. What makes VPN solutions unique with BIG-IP APM is not just the VPN element but the whole ecosystem within your hands, with multiple Multi-Factor Authenticaiton (MFA) and Single Sign-On (SSO) supported protocols. In addition to tight integration with different modules in BIG-IP. All this gives you as Solution Architect the flexibility to come up with different solutions that suits organizations security posture and expand well in the future for any new requirements. IPSEC VPN You can configure an IPsec tunnel to secure traffic that traverses a wide area network (WAN), from a BIG-IP system to third-party device. You start by configuring an IKE peer to negotiate Phase 1 Internet Security Association and Key Management Protocol (ISAKMP) security associations for the secure channel between two systems. You can also configure a custom traffic selector and a custom IPsec policy that use this secure channel to generate IPsec Tunnel mode (Phase 2) security associations (SAs). While IPSEC is configured via BIG-IP LTM, I've added this one here to cover the different VPN solutions, interesting set of articles already published covering different use cases and troubleshooting items for IPSEC VPN via BIG-IP. BIG-IP to Azure Dynamic IPsec Tunneling Securing ExpressRoute with the BIG-IP and IPsec Simple BIG-IP to BIG-IP, On-prem to Public Cloud IPsec Configuration Guide Understanding IPSec IKEv1 negotiation on Wireshark Understanding IPSec IKEv2 negotiation on Wireshark Passthrough IPSec with AFM SSL VPN Because an SSL VPN uses standard web browsers and technologies, it gives users secure remote access to enterprise applications without requiring the installation and maintenance of separate client software on each user’s computer. Most SSL VPNs also integrate with multiple authentication mechanisms. With the growth of the remote workforce, SSL VPNs are critical to keeping employees connected to the work applications they need—and for IT to ensure that only authorized users gain access. SSL VPNs provide a secure way for your workforce, contractors, and partners worldwide to gain access to sensitive information from virtually any computer or device. Furthermore, they give IT full, granular control over data access. SSL VPNs are becoming more common in the workplace, and the learning curve to implement and use them is minimal. Below are some of the use cases and education resources for VPN deployments via BIG-IP APM. Deploying a VPN on the BIG-IP APM Creating a SSL VPN Using F5 Full Webtop F5 VPN Client from Raspberry Pi SSL VPN Split Tunneling and Office 365 Scaling SSL VPN using BIG-IP Local Traffic Manager (LTM) Rate Limiting SSL VPN User Traffic VPN Split Tunneling: The Benefits and Risks SSL VPN Split Tunneling and Office 365 Remote Desktop Protocol (RDP) using an SSL VPN VPN Access with MFA using Edge Client 7.2.1 and APM 16.0 Connect to the F5 VPN with BIG-IP Edge Client How to optimize SSL VPN connections when BIG-IP is reaching 100% CPU Per-App VPN The Per-Application (Per-App) VPN feature makes sure that specific mobile applications and their data remain secure and protected, and only data relevant from the application is sent to the internal network. With the Per-App VPN capabilities of the BIG-IP APM, combined with a mobile device management (MDM) solution, enterprise organizations can be sure only authenticated and authorized mobile users are able to access and send data to the organization from approved mobile applications or mobile containers. Per-App VPN deploys using an existing MDM solution. Depending on the authentication in use, Per-App VPN can offer a seamless or relatively simple way to access internal resources. You can apply per-user bandwidth policies and ACLs to make sure that users comply with network use policies. Detailed user activity auditing is also possible with ACL logging or solutions based on iRules. You must create the following BIG-IP components for this implementation: A connectivity profile An application tunnel profile (Java and per-App VPN) An MDM-enrolled mobile device An MDM-deployed application BIG-IP Edge Client 2.0.1+ for L3 and Per-App VPN Application tunnel An application tunnel provides secure, application-level TCP/IP connections from the client to the internal network. Application tunnels use iSession, an F5 proprietary protocol for transport. Application tunnels can be started using native Windows binary components or with a browser-based Java applet on Windows, Mac, and Linux platforms. Per-user session-level bandwidth policy and ACLs can be applied to application tunnels. You must create the following BIG-IP components for this implementation: A connectivity profile A full webtop An application tunnel resource An access policy that assigns a webtop and an application tunnel resource Related content Configuring a Per-App VPN Using F5 App Tunnels Deploying a VPN on the BIG-IP APM Creating a SSL VPN Using F5 Full Webtop F5 VPN Client from Raspberry Pi SSL VPN Split Tunneling and Office 365 Scaling SSL VPN using BIG-IP Local Traffic Manager (LTM) How to optimize SSL VPN connections when BIG-IP is reaching 100% CPU BIG-IP to Azure Dynamic IPsec Tunneling Understanding IPSec IKEv1 negotiation on Wireshark Understanding IPSec IKEv2 negotiation on Wireshark Passthrough IPSec with AFM K08200035: Use cases | BIG-IP APM operations guide Configuring IPsec in Tunnel Mode between a Remote Device and BIG-IP using Dynamic TemplateF5 BIG-IP Access Policy Manager (APM) - Google Authenticator and Microsoft Authenticator
Introduction Lab guide Phase 1: Token Generation Phase 2: Token verification Related Content Introduction In our walkthrough we are refreshing an existing time-based one-time password (TOTP) deployment Two-Factor Authentication With Google Authenticator And APM In our walkthrough we are following the below assumptions, Secret key is generated outside of F5 and saved to Active Directory (AD) user attribute. F5 APM should be able to query AD user attribute (for example, in our case it's called serialNumber). We have two separate portals, One portal for Token generation and QR scanning. One portal for Application access. Lab guide Phase 1: Token Generation User logs in to the token generation portal and authenticates with AD credentials. F5 APM authenticates the user with AD and query the attribute for the secret key. F5 APM presnets the QR code for the user to be scanned whether by Google or Microsoft Authenticators. Phase 2: Token verification User Access the application and authenticates with AD credentials. Once user is successfully authenticated, the user is prompted to provide the one-time password (OTP). Once F5 verifies the provided OTP, the user is allowed to access the application. Verification iRule when ACCESS_POLICY_AGENT_EVENT { if { [ACCESS::policy agent_id] eq "ga_code_verify" } { ### Google Authenticator verification settings ### # lock the user out after x attempts for a period of x seconds set static::lockout_attempts 3 set static::lockout_period 30 # logon page session variable name for code attempt form field set static::ga_code_form_field "ga_code_attempt" # key (shared secret) storage method: ldap, ad, or datagroup set static::ga_key_storage "ad" # LDAP attribute for key if storing in LDAP (optional) set static::ga_key_ldap_attr "google_auth_key" # Active Directory attribute for key if storing in AD (optional) set static::ga_key_ad_attr [ACCESS::session data get "session.ad.last.attr.serialNumber"] # datagroup name if storing key in a datagroup (optional) set static::ga_key_dg "google_auth_keys" ##################################### ### DO NOT MODIFY BELOW THIS LINE ### ##################################### # set lockout table set static::lockout_state_table "[virtual name]_lockout_status" # set variables from APM logon page set username [ACCESS::session data get session.logon.last.username] set ga_code_attempt [ACCESS::session data get session.logon.last.$static::ga_code_form_field] # retrieve key from specified storage set ga_key "" switch $static::ga_key_storage { ldap { set ga_key [ACCESS::session data get session.ldap.last.attr.$static::ga_key_ldap_attr] } ad { set ga_key [ACCESS::session data get "session.ad.last.attr.serialNumber"] } datagroup { set ga_key [class lookup $username $static::ga_key_dg] } } # increment the number of login attempts for the user set prev_attempts [table incr -notouch -subtable $static::lockout_state_table $username] table timeout -subtable $static::lockout_state_table $username $static::lockout_period # verification result value: # 0 = successful # 1 = failed # 2 = no key found # 3 = invalid key length # 4 = user locked out # make sure that the user isn't locked out before calculating GA code if { $prev_attempts <= $static::lockout_attempts } { # check that a valid key was retrieved, then proceed #Update the key length based on the organization requirements if { [string length $ga_key] == 16 } { # begin - Base32 decode to binary # Base32 alphabet (see RFC 4648) array set static::b32_alphabet { A 0 B 1 C 2 D 3 E 4 F 5 G 6 H 7 I 8 J 9 K 10 L 11 M 12 N 13 O 14 P 15 Q 16 R 17 S 18 T 19 U 20 V 21 W 22 X 23 Y 24 Z 25 2 26 3 27 4 28 5 29 6 30 7 31 } set ga_key [string toupper $ga_key] set l [string length $ga_key] set n 0 set j 0 set ga_key_bin "" for { set i 0 } { $i < $l } { incr i } { set n [expr $n << 5] set n [expr $n + $static::b32_alphabet([string index $ga_key $i])] set j [incr j 5] if { $j >= 8 } { set j [incr j -8] append ga_key_bin [format %c [expr ($n & (0xFF << $j)) >> $j]] } } # end - Base32 decode to binary # begin - HMAC-SHA1 calculation of Google Auth token set time [binary format W* [expr [clock seconds] / 30]] set ipad "" set opad "" for { set j 0 } { $j < [string length $ga_key_bin] } { incr j } { binary scan $ga_key_bin @${j}H2 k set o [expr 0x$k ^ 0x5C] set i [expr 0x$k ^ 0x36] append ipad [format %c $i] append opad [format %c $o] } while { $j < 64 } { append ipad 6 append opad \\ incr j } binary scan [sha1 $opad[sha1 ${ipad}${time}]] H* token # end - HMAC-SHA1 calculation of Google Auth hex token # begin - extract code from Google Auth hex token set offset [expr ([scan [string index $token end] %x] & 0x0F) << 1] set ga_code [expr (0x[string range $token $offset [expr $offset + 7]] & 0x7FFFFFFF) % 1000000] set ga_code [format %06d $ga_code] # end - extract code from Google Auth hex token if { $ga_code_attempt eq $ga_code } { # code verification successful set ga_result 0 } else { # code verification failed set ga_result 1 } } elseif { [string length $ga_key] > 0 } { # invalid key length, greater than 0, but not length not equal to 16 chars set ga_result 3 } else { # could not retrieve user's key set ga_result 2 } } else { # user locked out due to too many failed attempts set ga_result 4 } # set code verification result in session variable ACCESS::session data set session.custom.ga_result $ga_result } } Related Content Two-Factor Authentication With Google Authenticator And APM Demystifying Time-based OTP Google Authenticator Token Verification iRule For APM APM Google Authenticator HTTP API Google Authenticator Verification iRule (TMOS v11.1+ optimized) UDF Lab Configuring MFA OTP Note, Scan the Article photo for more BIG-IP Access Policy Manager (APM) info.OWASP Tactical Access Defense Series: How BIG-IP APM Strengthens Defenses Against OWASP Top 10
In an era where cyber threats loom large, safeguarding digital assets has become paramount. Among the vanguard of defenders stands the F5 BIG-IP Access Policy Manager (APM), a stalwart guardian against the notorious OWASP Top 10 vulnerabilities. In this article, we embark on a journey through the tactical strategies employed by BIG-IP APM, unraveling how it reinforces the fortifications against these pervasive threats. From dynamic access controls to multifaceted authentication protocols, BIG-IP APM stands as a beacon of resilience in the face of evolving security challenges. Join us as we delve into the intricacies of BIG-IP APM's role in shoring up defenses, ensuring your digital landscape remains a fortress impervious to OWASP's formidable arsenal. OWASP The OWASP (Open Web Application Security Project) API (Application Programmable Interface) Security project aims to help the organizations by providing a guide with a list of the latest top 10 most critical API vulnerabilities and steps to mitigate them. As part of updating the old OWASP API Security risk categories of 2019, recently OWASP API Security Top 10 2023 is released. Introduction to OWASP API Security Top 10 2023 lists the updated top 10 list and the explanation for each one, in our series we focus more on the access related items. BIG-IP APM Within the realm of access security, BIG-IP APM emerges as a pivotal player, offering more than just session awareness and enforcement capabilities. Its unique strength lies in its capability to handle per-request calls, providing an unprecedented level of granularity in securing API endpoints. BIG-IP APM's prowess extends beyond session management; it boasts per-request awareness, enforcing rigorous authentication and authorization protocols on API requests directed towards safeguarded endpoints. This distinctive feature ensures robust protection for your digital assets. As we delve deeper into this series of articles, we'll uncover how BIG-IP APM significantly bolsters your defense strategy in addressing the critical challenges outlined in the OWASP top 10 API vulnerabilities. Stay engaged to explore the comprehensive capabilities of BIG-IP APM and how it plays a pivotal role in fortifying your security posture against these formidable threats. Related Content F5 BIG-IP Access Policy Manager | F5 OWASP Tactical Access Defense Series: Broken Object Level Authorization and BIG-IP APM Introduction to OWASP API Security Top 10 2023 OWASP Top 10 API Security Risks – 2023 - OWASP API Security Top 10OWASP Tactical Access Defense Series: Broken Object Level Authorization and BIG-IP APM
Addressing Broken Object Level Authorization (BOLA) vulnerabilities requires a multifaceted approach, combining robust coding practices, secure development methodologies, and powerful tools. Among these tools, F5 BIG-IP Access Policy Manager (APM) stands out as a crucial component in the arsenal of security measures. This article, the second in a series of articles dedicated to fortifying application security, delves into the pivotal role that BIG-IP APM plays in identifying, mitigating, and ultimately preventing OWASP top 10 API vulnerabilities byproviding developers and security professionals with a comprehensive guide to bolstering application security in the face of evolving cyber threats. Broken Object Level Authorization This is one of the most common and severe vulnerabilities within APIs and is related to Insecure Direct Object References (IDOR). Starting with, what's Object Level Authorization? This is an access control mechanism that's in place to validate which user has access to a specific endpoint and what actions to be performed. BOLA and IDOR refer to situations where the endpoints fail to enforce specific authorization rules on endpoints, or the user is successfully able to access unauthorized endpoints and perform unauthorized actions. The weakness that can lead to this vulnerability is the server component fails to track client state and rely on other parameters that can be tweaked from the client side, for example (Cookies, object IDs). BOLA Example Let's assume this backend directory, - /uploads/ - user1/ - file1.txt - file2.txt - user2/ - file3.txt - file4.txt The expected user1 usage is as follows, https://example.com/viewfile?file=file1.txt the user can access file1. If the server is vulnerable to BOLA, let's have user2 accessing the server, then try to navigate to file1 as follows, https://example.com/viewfile?file=user1/file1.txt What could help us in this situation? Yes, we need granular endpoint authorization with proper client state tracking. That's where our lovely friend BIG-IP APM comes into the picture. Let's see how BIG-IP APM can help us. BIG-IP APM and BOLA protection BIG-IP APM provides API protection through its Per-Request policy, where the it applies granular Access protection to each API endpoint. How BIG-IP APM enhancesdefenses We start with creating our Per-Request policy, this policy works in a different way than the per-session policy, as the flow will be evaluted on a per-request basis, making sure to consider variations throught the session life-time. Below are some of the key benefits: Wide range of Authentication, SSO, and MFA mechanisms to properly identify the initiating machine or user. Ability to integrate with 3rd parties to provide additional enforcement decisions based on the organization's policy. Ability to apply endpoint checks on the client side before session initiation. This goes to BIG-IP in general, the ability to apply custom traffic control on both of the traffic sides, Client and Server. Using BIG-IP API protection profile. Protection profiles are an easy way to deploy both APM (Per-Request policy) and Advanced Web Application Firewall (AWAF). As a pre-requisite, you need APM, AWAF licensed and provisioned. Use OpenAPI Spec 2.0 as an input to the API protection. Apply different Authentication methods, whether Basic, Oauth (Directly from the template), or once we have the API protection profile created, we can customize policy elements to our needs. Using Hybrid approach with F5 Distributed Cloud (F5 XC) + BIG-IP APM We had this approach discussed in details through F5Hybrid Security Architectures (Part 5 - F5 XC, BIG-IP APM, CIS, and NGINX Ingress Controller) Stay engaged to explore the comprehensive capabilities of BIG-IP APM and how it plays a pivotal role in fortifying your security posture against these formidable threats. Related Content F5 BIG-IP Access Policy Manager | F5 Introduction to OWASP API Security Top 10 2023 OWASP Top 10 API Security Risks – 2023 - OWASP API Security Top 10 API Protection Concepts OWASP Tactical Access Defense Series: How BIG-IP APM Strengthens Defenses Against OWASP Top 10 F5 Hybrid Security Architectures (Part 5 - F5 XC, BIG-IP APM, CIS, and NGINX Ingress Controller)Federated AWS Console Access Made Easy: F5 BIG-IP Access Policy Manager Access Guided Configurations
Introduction In the following guide we are configuring Federated AWS Console Access through BIG-IP APM as Identity Provider (IdP). With AWS console we need to be very careful about granting access, checking endpoint and apply Multi-Factor Authentication (MFA). Architecture The expected traffic flow follows the below path, User Access F5 APM portal. F5 APM applies EndPoint inspection and user authentication. Once the user is authenticated, APM redirects user browser to AWS Console with SAML assertion. AWS Console verifies the assertion, the assigned role and allow the proper access to the user. Configurations steps let's list the steps to perform the configurations. F5 APM Configurations Head to Access > Access Guided Configurations > Select SAML Identity provider template Configure IdP settings. Configure Virtual Server settings or select one that's already created. Specify Authentication and MFA settings. Select proper SaaS Application template (Amazon Web Services in our case) Configure the AWS Application settings, Mention IdP name configured at AWS console. Mention IdP role name created at AWS console. EndPoint checks and inspection Then adjust session management parameters as per requirements and customization for the web portal and Deploy. Here's how the final policy should look like, Note, you can make use of authentication part to fetch the proper role per user and communicate that to AWS Console, so each user is assigned to the proper role. AWS Console Configurations Create IdP settings from AWS Console > IAM > Identity Providers Make sure to assign proper roles to the Identity Provider and make sure the role got "sts:AssumeRoleWithSAML" Allow. Conclusion Using Access Guided Configurations, it's easy to secure and simplify access to AWS Console and we can extend our existing Identity services to facilitate and authorize access to AWS Console. In addition to authorizing users, you can make use of F5 APM endpoint inspection and further integrations with 3rd parties through HTTP connectors and iRules. Related Contents Overview of F5 Guided Configuration Guided Configuration 10.0 Creating IAM identity providers Enabling SAML 2.0 federated users to access the AWS Management Console
