Imperva Cyber Community

communities_1.jpg
 View Only
  • 1.  [Cloud WAF] cross site scripting whitelisting for specific url (/abc) with geolocation ip - alert only

    Posted 02-02-2024 01:16
    Edited by John Thompson 02-05-2024 00:58

    Hello practitioners,

    What is the effective way to mitigate a  cross site scripting attack on a SPECIFIC URL (/abc) where geolocation is activated- allow ip address within a country  and log mode is Alert Only?

    Im hesitant in having this WHITELISTING logic setting since users around the country are accessing this url.

    May tips on how we can investigate or gather information 

    #Whitelist
    #GeoBlocking
    #GeoLocation
    #XSS

    More power,

    A


    #CloudWAF(formerlyIncapsula)

    ------------------------------
    [Leangf]
    ------------------------------



  • 2.  RE: [Cloud WAF] cross site scripting whitelisting for specific url (/abc) with geolocation ip - alert only

    Posted 02-04-2024 20:28

    GREAT QUESTION @Angfe Landagan!! 

    *Note: you may enjoy this post that touches on a similar issue from a different perspective: https://community.imperva.com/discussion/can-we-setup-a-source-ip-filtering-based-on-the-url#bm9581a243-38a2-4b22-b335-e7402f339461   @Jaired Anderson - would you be willing to weigh-in on the different between the question above and the referenced article you posted on previously?

    Your question raises something that everyone should fully understand, so I hope you'll indulge my expanding upon your initial ask.  The differences between setting an "ALLOWLIST" on an IP Address or a larger Subnet Range vs. a WAF > WAF Policies > WAF Rule with or w/o an Exception and/or individual application vs. a custom Security Rule (under Websites > Security > Rules) for a site are important for all to understand. Our AppSec specialist, @Chris Stensager, and I were just discussing how important it is to use the appropriate configuration or tool for the job, so it's fortituous that you just raised this question.  :-) 

    As this documentation regarding Allowllists states, such traffic (ie.. allow-listed traffic) will "not [be] inspected by Imperva WAF and Security Settings".  It is for this reason that I council customers to use the sparingly for fully trusted IPs (eg.. 3rd party Web Vulnerabilty Scanning companies, penetration testers [when you want their attacks to evaluate the origin server itself, or to compare and contrast vulnerabilities with and without mitigation as part of a virtual patching program, etc.], etc.)
    https://docs.imperva.com/bundle/cloud-application-security/page/policies.htm#Policy

    CWAF > Create and Manage Policies > Policy Types

    A custom rule in Websites > Security > Rules (Security, Redirect, Rates, Rewrite Request, Forward, Rewrite Response, Override WAF Settings) for a website, however, allows you to build custom IF/Then and XOR statements so that you may be more precise or surgical; if the situation calls for that.  See the following for details:

    Using a custom security rule you can be more surgical with your security rules at the web site level.

    @Chris Stensager, @Jaired Anderson, @Pathik Shah@Luke Babarinde, @Peter Klimek, @Daniel Toh@Rodolfo Galvan, @Cole Tjepkes, @Santosh Nallu, @Darren Harter, @Aaron Willis, @Ayman Karamalla, @Gabriele Buratti - Can you expand on the above posts?

    Thanks,

    – JT



    ------------------------------
    John Thompson
    Director, Channel Presales
    Imperva
    San Diego CA
    ------------------------------



  • 3.  RE: [Cloud WAF] cross site scripting whitelisting for specific url (/abc) with geolocation ip - alert only

    Posted 02-04-2024 20:44

    Now to address your specific question @Angfe Landagan, I've invited other AppSec experts to comment, but I don't believe you can do what you're asking in the way you're asking how to do it.

    However, to accomplish the result you're looking for, I believe you'd have to create a new WAF Policies > WAF Rule with a specific exception for the IP address(es) or range that you want to allow for Cross-Site Scripting, then disable/remove or edit the Allowlist policy as appropriate to stop ignoring that specific IP traffic.  Then test that your custom WAF Rule with the exception is working.

    Alternatively, if you have identified specifics and/or parameters of the cross-site scripting attack(s) going on, you could craft a custom Security Rule to mitigate that attack(s) with or w/o the IP exception being asking about regarding the Allowlist.  Also, depending upon the type of attack specifics, you could layer additional mitigations in place like Runtime Protection (RASP)Advanced Bot Protection, OnPrem WAF, etc. to truly leverage defense in depth.

    #RASP #AdvancedBotProtection #CloudWAF #On-PremisesWAF(formerlySecuresphere) #Defense-in-Depth #CrossSiteScripting #WAFRules #SecurityRules #SecurityPolicies #ApplicationSecurity

    – JT



    ------------------------------
    John Thompson
    Director, Channel Presales
    Imperva
    San Diego CA
    ------------------------------



  • 4.  RE: [Cloud WAF] cross site scripting whitelisting for specific url (/abc) with geolocation ip - alert only
    Best Answer

    Posted 02-13-2024 15:16

    Hello,

    My apologies for the delay in responding.

    I'm not sure I understand the desired outcome.

    What is the effective way to mitigate a  cross site scripting attack

    There is an XSS WAF policy that will mitigate this. Is this policy enabled?

    on a SPECIFIC URL (/abc)

    The XSS policy applies to all URLs. However, you can craft custom Security rules.

    where geolocation is activated
    Is this in reference to a geolocation ACL policy that you have applied?

    - allow ip address within a country
    Is this in reference to an AllowList policy? If so, these should be used with caution and only when absolutely necessary. Any IP within the AllowList will bypass ALL security controls. 

     and log mode is Alert Only?
    Is this in reference to the WAF XSS policy I mentioned above, or a custom security rule?

    There are essentially 2 scenarios:

    1.) WAF XSS is currently set to Alert, but you want to block XSS on a specific URL

    or

    2.) WAF XSS is currently set to Block, but you want to allow XSS on a specific URL. 

    Which scenario is more applicable to your situation?



    ------------------------------
    Jaired Anderson
    Imperva
    https://www.imperva.com/
    ------------------------------



  • 5.  RE: [Cloud WAF] cross site scripting whitelisting for specific url (/abc) with geolocation ip - alert only

    Posted 02-07-2024 22:31
    Edited by John Thompson 04-26-2024 12:08
    Story Time:
    This scenario reminded me of a customer story from a few years ago when an organization's security and admin team hadn't recognized what they'd unintentionally done.  
     
    I'm hoping that it's an educational (and maybe even fun) sharing of something that can happen when we are unable to practice Defense-In-Depth or don't practice what Ted Lasso so wisely teaches us about when he says, "Be Curious."
     
    In any case, I was working with an organization on the 2nd day of an engagement, and I was working with the staff, monitoring traffic, reviewing alerts, tuning the config, etc. (ie.. the normal stuff)  When I happened upon a SQL Injection violation.  It's not necessarily uncommon to see one, but this one was from an RFC1918 address (eg.. 10.10.3.4), it was with an account I recognized to be a default and highly privileged system account for the database, and it was a non-obfuscated, and rather long SQL query.  I spent a little time researching it, reviewing the other related violations on the same alert, and making sure I had my facts straight.
     
    Then, I called over my technical contact at the organization, asking them to take a look at the SQL Injection I had up on the screen, calling their attention to the IP and related violations, etc.  After possibly as long as 10-seconds, their response was, "That's a false positive. Just allow it.
    ** Now, don't get ahead of me in this story.  just stick with me here... **
     
    I told them that I disagreed with them because of the: a) system user, b) the internal IP, c) the complexity of the SQL Command itself (it was at least 1000 characters long), and d) the query was successful in returning a significant volume of sensitive (ie.. "Private") data.  So, I asked my contact if they could clarify why they considered it a false positive.  I mean, they certainly know their environment better than I did, but this was triggering multiple red flags for me...
     
    The engineer spent a few more seconds reviewing the alert data, and then yelled across the cube farm to a network engineer and asked "Who is 10.10.3.4?"  The response yelled back was that it was "Customer X."  My contact again said, "Oh yeah, that's OK, you can allowlist that. We told them how to do that."  
     
    Well now, my curiosity was really piqued, and so I said, "That's interesting.  Could you explain that to me a little bit more?"  
     
    I believe at that point, the engineer thought I was a bit dense, but they indulged me and shared the following details. And as I continued to dig deeper and ask "Oh, tell me more about that." or "Can you expand on that a little more?" they shared the following salient data points with me:
    1. Their organization provided a SaaS solution to a niche market segment that was COTS Software (or OEM perhaps) that they then made available as a service to a specific vertical.
    2. Since the SaaS solution they provided was really COTS or OEM software; they could not modify the software/code
    3. The customers of this business organization were presumed to be "trusted" because they were all connected to this business over MPLS, VPN, or Dedicated Connections
    4. Customer X was a very important customer to this organization.
    5. Customer X wanted a custom report created for them to comply with some audit or routine processing, etc.
    6. The COTS software provided no capability to create custom reports.
    7. The organization's leadership told their Lead DBA to solve the problem for their "VIP customer." 
    8. The DBA being a brilliant developer/engineer created a custom SQL query that would deliver the custom dataset/report that Customer X wanted using their existing client application. 
    9. The COTS client had the system account embedded (hardcoded) in it.
    10. The organization and its flagship product in question organized all of its customer's data in a centralized and shared datastore.
    11. Customer X is the only customer (organization) that was given this SQL query.

    ** <Please Pause here for a moment> **
    Now, if you're tracking along with this, I would love for you to please put yourself in my position, understanding the Risk involved in this situation/environment, and reply to this post with the first response that would come to your mind for you in that situation.  Please Reply first; then, <scroll down to continue>
    .
    .
    .
    .
    .
    .
    .
    .
    .
    .
    .
    .
    .
    .
    .
    .
    .
    .
    .
    .
     
    Okay, back to the customer story...  I explained to the engineer, and eventually to their DBA as well, that with that embedded system account, and the fact that they had "admin" level permission to their organization's shared datastore, they could actually change a few variables, or send a different query entirely, and retrieve additional data for their organization's data or another organization in the shared datastore, or dump the database, etc...
     
    I suggested that we could the following, and then implemented it:
    • Create a signature for that single query they provided to their VIP customer, to match against, 
    • Then, create an exception to the general SQL Injection rule for "Customer X and that signature specifically." So that we'd eliminate the SQLi alerts we were receiving, yet were expected. 
    • Create a custom security policy to match on the use of that specific signature and customer-specific IPs, as "alert only", so that they could monitor the usage of that signature/query if they wanted to.  We used this policy during initial testing.
    • And then, create another custom security policy to block SQL injection attacks from Customer X that did not match that specific signature/query.  We implemented this as an alert only during the first few weeks initially.
    • Impress upon their leadership the need to have the custom report capability implemented as a feature in a future version of the COTS software they used, and to have the embedded admin account model in that software changed ASAP.
    • They needed an additional way to protect their data. eg.. find a way to segment their customer data, or tokenize it, or implement customer-specific encryption, etc...  
     
    So, a few of the lessons learned that day were: 
    1. Implicitly trusting a customer (or Business Partner) organization to either not be malicious, compromised, or just "curious", they'd have unfettered access to all of their SaaS provider's customers' data (if they chose to exercise that ability.)
      1. In my opinion, the concept of Zero Trust was not widely known at the time.  If it had been, I like to think that multiple tenants, and multiple steps in the process/framework of zero trust would have exposed the multiple problems above.  Looking at it as a tabletop exercise, it seems like a comedy of errors, but I know that when different people are involved in just their piece of it, over time, it's easy to miss the warning signs that jump out at us in review.
    2. By not having any solutions in place to provide visibility, protection, or control, they'd never have known if someone was accessing more data than they were "supposed to", and their organization was put at significant risk.
    3. The Separation of Duties provision in NIST and SOX and other industry regulations is really important and makes a lot of sense in terms of Risk and Cybersecurity.
    4. This organization could have benefited from Data Risk Analytics and it's zero false positives.
    .
    This story is about a specific organization being instructed on how to successfully initiate a SQL Injection attack against their own data, but that same capability was available to the 300+ other organizations that were customers of the organization I was working with.  And any compromised, malicious, bored, or curious users (ie.. the "Insider Threat") at any of those 300+ customer organizations could have just as easily leveraged their existing access to do the same thing, that the business specifically instructed one of their customers how to do themselves.
     
    It's really pretty scary to think about, but I'd love to hear your feedback
     
     



    ------------------------------
    John Thompson
    Director, Channel Presales
    Imperva
    San Diego CA
    ------------------------------