allow the Public NAT gateway of the client's network). Create an 'Allow list' of specific IP addresses or IP Address ranges of users originating from within the clients network.To address possible false positives, clients have the following options: However, LabKey Server ensures that only trusted users in the Developer role are allowed to embed JavaScript in wikis. However, LabKey Server's query engine ensures that any SQL used is safe.Īs a second example, saving an HTML-based wiki page that contains JavaScript can look like a cross-site scripting (XSS) attack to a WAF. These types of activities are difficult to distinguish from malicious activities as the methods used to upload malicious code is indistinguishable from normal workflows.įor example, editing a SQL query and saving it within the Query Schema Browser APIs can look like a SQL injection attack to a WAF.

Many LabKey core APIs and user interfaces involve SQL, JavaScript, and other developer-oriented features. Required AWS Permissions to use CloudFormation, WAF, IAM Policies, S3, Lambda, etc.Configured Elastic Load Balancer with target group routing to LabKey EC2 Instance.Using the AWS WAF as an example, review their documentation here: Deploying a Web Application Firewall (WAF) can protect against the OWASP top 10 vulnerabilities and many malicious bot networks. Fortunately there are some easy and low cost tools to protect against many attacks. Typically motivated by financial extortion, these individuals use DDoS and bot networks to attack victims. Public-facing LabKey instances are subject to 'internet background radiation' by nefarious miscreants who seek to comprise systems to gain access to protected data. The example in this topic uses AWS, but other firewall options can be configured similarly to protect your LabKey Server. This topic outlines the process for deploying an Web Application Firewall (WAF) to protect LabKey instances from DDoS (Distributed Denial of Service) and other malicious attacks.

Aws web application firewall