Quick Checklist: What to Whitelist

Architecture Patterns

Sample Rules

Azure: Firewall Policy (FQDN-based)

{
  "ruleCollectionGroups": [{
    "name": "uat-egress",
    "priority": 200,
    "ruleCollections": [{
      "name": "allow-apis",
      "priority": 100,
      "action": { "type": "Allow" },
      "rules": [{
        "name": "allow-stripe",
        "ruleType": "ApplicationRule",
        "protocols": [{ "protocolType": "Https", "port": 443 }],
        "sourceAddresses": ["10.20.0.0/16"],
        "targetFqdns": ["api.stripe.com"]
      },{
        "name": "allow-msft-graph",
        "ruleType": "ApplicationRule",
        "protocols": [{ "protocolType": "Https", "port": 443 }],
        "sourceAddresses": ["10.20.0.0/16"],
        "targetFqdns": ["graph.microsoft.com", "login.microsoftonline.com"]
      }]
    },{
      "name": "deny-all",
      "priority": 900,
      "action": { "type": "Deny" },
      "rules": [{
        "name": "block-rest",
        "ruleType": "ApplicationRule",
        "protocols": [{ "protocolType": "Http", "port": 80 }, { "protocolType": "Https", "port": 443 }],
        "sourceAddresses": ["10.20.0.0/16"],
        "targetFqdns": ["*"]
      }]
    }]
  }]
}

AWS: VPC + Security Group (egress tighten)

Security Groups don’t support FQDNs; pair them with a NAT Gateway + Network Firewall for domain rules. At minimum, restrict SG egress to 443 and route through the firewall.

# Security Group (egress only to 443)
aws ec2 authorize-security-group-egress \
  --group-id sg-XXXX \
  --ip-permissions '[
    {"IpProtocol":"tcp","FromPort":443,"ToPort":443,"IpRanges":[{"CidrIp":"0.0.0.0/0"}]}
  ]'

# AWS Network Firewall (domain list) snippet via Suricata-style rules
pass tls $HOME_NET any -> $EXTERNAL_NET 443 (tls.sni; content:"api.stripe.com"; endswith; msg:"allow stripe"; sid:100001;)
pass tls $HOME_NET any -> $EXTERNAL_NET 443 (tls.sni; content:"graph.microsoft.com"; endswith; msg:"allow graph"; sid:100002;)
drop tls $HOME_NET any -> $EXTERNAL_NET 443 (msg:"deny unknown domains"; sid:199999;)

Proxy (Squid) Domain Allow-List

# /etc/squid/whitelist.txt
api.stripe.com
graph.microsoft.com
login.microsoftonline.com

# /etc/squid/squid.conf (excerpt)
acl allowed dstdomain "/etc/squid/whitelist.txt"
http_access allow allowed
http_access deny all
acl HTTPS_ports port 443
acl CONNECT method CONNECT
http_access allow CONNECT HTTPS_ports

Operational Controls

• Separate UAT credentials: distinct OAuth apps/API keys from prod; scope to least privilege.
• Secret handling: use a vault; never embed in code or images. Rotate regularly.
• DNS controls: internal resolver, logging, and (optionally) domain filtering.
• Monitoring: centralize egress logs; alert on connections to non-approved hosts.
• Change management: any new third-party API requires a ticketed update to the allow-list.
• Rate limiting: throttle UAT to avoid vendor abuse and surprise bills.
• Segregation: different egress IPs and rulesets for UAT vs prod; no shared service accounts.

Summary

Deny by default, allow the exact FQDNs and ports your tests need, and log everything. Pair tight network policy with proper identity, secret hygiene, and rate limits. UAT stays useful for testing — without becoming an easy path for data leaks or lateral movement.

The post Locking down UAT Environments appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.

Why CORS Is Important (And How to Secure It)

What is CORS and why is it important?

CORS (Cross-Origin Resource Sharing) is a browser security feature that restricts web pages from making requests to a different domain (or origin) than the one that served the web page.

It’s important because it:

• Prevents malicious websites from reading sensitive data from other sites.
• Ensures that only trusted domains can interact with your API or backend resources.
• Allows controlled flexibility for legitimate use cases like third-party integrations.

What is a “cross-origin” request?

A cross-origin request happens when the origin (scheme + domain + port) of the frontend differs from that of the backend.

Example:

Frontend: https://my.website.com  
Backend: https://api.website.com  
  

How does CORS work behind the scenes?

When your JavaScript code tries to fetch data from a different origin, the browser:

1. Sends a preflight OPTIONS request to the server.
2. The server responds with headers like:

   Access-Control-Allow-Origin: https://my.website.com
   Access-Control-Allow-Methods: GET, POST
   Access-Control-Allow-Headers: Content-Type
         

3. If allowed, the browser proceeds with the actual request.

What happens if CORS is misconfigured?

If your server sends headers like:

Access-Control-Allow-Origin: *

Then any website in the world can make API requests to your backend. This is dangerous if:

• Your API exposes sensitive data.
• The API uses cookies for authentication.
• You assume only your frontend will access the backend.

How can a hacker abuse poor CORS configuration?

1. The backend allows all origins via *.
2. A hacker builds a malicious site that calls your API using the victim’s browser.
3. The browser sends authentication cookies automatically.
4. The attacker gains access to data, impersonates users, or exfiltrates info.

Isn’t CORS enforced by the browser?

Yes — browsers enforce CORS. However:

• Mobile apps, Postman, cURL are not subject to CORS.
• CORS is only a client-side control. You still need server-side auth.

Can CORS be bypassed?

Direct bypasses aren’t easy, but developers can open the door accidentally:

• Echoing back the request’s Origin header without validation.
• Using Access-Control-Allow-Credentials: true with * (invalid).
• Allowing all origins with wildcards like http://*.

Best Practices for CORS Security

• Whitelist exact origins — no wildcards.
• Don’t allow * if using cookies or credentials.
• Don’t blindly echo back the Origin header.
• Use additional access control (JWT, API keys, RBAC).

If Serving JavaScript from Cloudflare

If your JavaScript is hosted via Cloudflare and served to browsers at https://my.website.com, then this is the only origin that should be allowed to access your backend at https://api.website.com.

Cloudflare is not the origin — the browser origin is still https://my.website.com. So, you whitelist that, not Cloudflare’s domain.

Correct CORS Headers for This Setup

For a backend at https://api.website.com and frontend at https://my.website.com, your server should return:

Access-Control-Allow-Origin: https://my.website.com
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Allow-Credentials: true
  

Example: Server-Side Logic for CORS

// Node.js/Express example
const allowedOrigins = ['https://my.website.com'];

app.use((req, res, next) => {
  const origin = req.headers.origin;
  if (allowedOrigins.includes(origin)) {
    res.setHeader('Access-Control-Allow-Origin', origin);
    res.setHeader('Access-Control-Allow-Credentials', 'true');
  }
  res.setHeader('Access-Control-Allow-Methods', 'GET, POST, OPTIONS');
  res.setHeader('Access-Control-Allow-Headers', 'Content-Type, Authorization');
  next();
});
  

Summary

• CORS is a critical security layer for browser-based apps.
• Always whitelist specific origins, especially if using cookies or auth tokens.
• Don’t use * unless you’re 100% sure it’s safe (and no credentials are involved).

CORS is your browser saying: “Are you sure this site is allowed to talk to that other one?” — don’t ignore it.

The post What the heck is CORs? Can CloudFlare help me with CORs security issues? appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.

Strict Transport Security Not Enforced

What Is HSTS?

HSTS (HTTP Strict Transport Security) is a browser-enforced policy that ensures a website is only accessed using HTTPS—even if a user types or clicks on an HTTP link.

It protects against man-in-the-middle (MITM) attacks like SSL stripping.

What Does the Warning Mean?

If a site doesn’t properly implement HSTS, tools like SSL Labs or browser developer tools may show the warning:
“Strict-Transport-Security not enforced”

• The site might allow insecure HTTP connections
• The required Strict-Transport-Security header is missing
• The max-age setting is too low to be effective

How to Fix It

Add the Strict-Transport-Security header to all HTTPS responses.

Example Header:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Header Breakdown:

• max-age=31536000: Enforce HTTPS for 1 year (in seconds)
• includeSubDomains: Apply to all subdomains
• preload: Eligible for browser HSTS preload lists

Where to Set It

Nginx:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Apache:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

Cloudflare:

• Navigate to SSL/TLS > Edge Certificates
• Enable HTTP Strict Transport Security (HSTS) and configure the options

Important Notes

• Only enable HSTS once your HTTPS setup is fully stable
• If you use preload, your domain will be included in browser preload lists and cannot be removed easily

Summary

The post Strict HTTP Transport Not Enforced appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.

Modern web applications often rely on APIs hosted on different domains — this is called cross-origin communication. While useful, this opens up potential attack vectors, especially if not properly controlled. That’s where CORS (Cross-Origin Resource Sharing) comes in.

Also read – Preventing CORS

What is CORS?

CORS is a browser security feature that controls how and whether frontend JavaScript running on one origin (e.g., https://app.example.com) can make requests to a different origin (e.g., https://api.example.com).

To permit this, the server must explicitly allow such access by setting CORS headers, particularly:

Access-Control-Allow-Origin: https://app.example.com

But what happens if you set:

Access-Control-Allow-Origin: *

This allows any domain to access your API — including malicious ones. This is rarely a good idea unless you’re serving public, non-sensitive content.

The Right Way: Restrict to a Whitelist

Why Whitelist Specific Origins?

• Prevents data theft by rogue JavaScript from untrusted websites
• Protects APIs that serve sensitive information (auth tokens, user data, etc.)
• Mitigates risks from phishing sites attempting to access user sessions

Important Security Tips

• Never use Access-Control-Allow-Origin: * with cookies or authorization headers
• Always validate the Origin header on the server, not the client
• Log CORS rejections for debugging and security audits
• Consider using a dynamic origin check if the list is large or changes often

CORS is dangerous

CORS is a powerful but dangerous gate. While it enables useful cross-origin interactions, it must be tightly controlled to avoid exposing your users and systems to cross-site attacks.

Whitelist only what you trust. Log what you reject. Audit your CORS rules regularly.

CloudFlare versus Server Code Whitelist

How to Implement CORS Whitelisting (Server-Side Examples)

Example in Node.js / Express

const allowedOrigins = ['https://app.example.com', 'https://admin.example.com'];

app.use((req, res, next) => {
  const origin = req.headers.origin;
  if (allowedOrigins.includes(origin)) {
    res.setHeader('Access-Control-Allow-Origin', origin);
  }
  res.setHeader('Access-Control-Allow-Methods', 'GET,POST,PUT,DELETE');
  res.setHeader('Access-Control-Allow-Headers', 'Content-Type,Authorization');
  next();
});
  

Example in Python / Flask

from flask import Flask, request
from flask_cors import CORS

app = Flask(__name__)
allowed_origins = ['https://app.example.com', 'https://admin.example.com']

def custom_cors(origin):
    return origin in allowed_origins

CORS(app, origins=custom_cors)
  

Example in .NET (ASP.NET Core)

var allowedOrigins = new[] { "https://app.example.com", "https://admin.example.com" };

builder.Services.AddCors(options =>
{
    options.AddPolicy("RestrictedPolicy", policy =>
    {
        policy.WithOrigins(allowedOrigins)
              .AllowAnyHeader()
              .AllowAnyMethod();
    });
});

The post Restricting CORS origin to a WHITELIST appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.

Often, a copy of Production data (i.e. in a database) is needed over in a non production environment (in the public cloud). This would entail moving data between a PRODUCTION VPC / VNET  and a non production VPC / VNET. This post assumes that the source data is in a production database (either on premises or on the cloud) and the target is also another database (again, eitehr cloud hosted or on premises database).

Some Scoping Questions

1. The first question to ask is the ‘recovery time’ or the replication time required to replicate the data.
2. The second question to ask is the security constraints around the movement of the data.

Based on these answers, common solutions for replicating production data including

1. Backup and Restore (of the actual filesystem to a cloud blob storage service)
2. Snapshots of Production Data (of the Server containing the database)
3. Using Shared Volumes (e.g. with a Netapp type of appliance).

Backup and Restore (using a blog storage service on the public cloud) 

Backups generate copies of your data files. This could take anywhere from minutes to days.

Snapshots – A Quicker form of backups

Snapshot SNAP to an instantaneous picture of your file system at a point in time. A snapshot is used typically, to restore the server back to the point in time.

Most standard databases (SQL Server, Oracle…) allow for manual snapshotting at any time.

Snapshots versus Backups

Backups can be stored in a different location from the original data whereas a snapshot, can only exist in the same location as the original data.

Snapshots by themselves are not backups. However, they are an essential part of the backup process (part of the data movement process to a backup file).

Using Shared Volumes (e.g. with a Netapp type of appliance).

The appliance would need to reside in it’s own subnet, which might be in the production VNET/VPC. However, the advantage of such an appliance is that it provides enhanced export options – i.e. additional security controls over which environment to export / copy volumes to.

The export time / recovery time would be in the minutes as opposed to hours.

The post Production Data Copy Options on the Public Cloud appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.

However, this particular risk is easily mitigated by intelligent firewall policies. In fact,  domain membership will make the firewall configuration easier and more secure.

Advantages of Domain Membership:

• Granular user/group access controls for all protocols
• Full support for user certificate authentication
• Full support for Group Policy management

Disadvantages of Domain Membership

• If your firewall is compromised, your entire domain may be at risk. However, keep in mind that if your firewall is compromised, there is little on your network that is not at risk.

Summary

While ‘security’ concerns are most often cited to keep servers (IIS servers, DB Servers, App Servers…) off domains (i.e. are NOT domain joined), these concerns are old school. With newer firewall technologies, the best practice actually involves Domain-Joining all the servers you need to. Of course, keeping your data tier in it’s own VLAN – separated from the web-tier would be part of the best practices.

The post To Domain Join or Not appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.

• Factor 1 – Something you know (PIN,  password, secret questions, etc);
• Factor 2 – Something you have ( token, key, smartcard, mobile phone) or  Something you are (biometrics such as fingerprint, retina, voiceprint etc.)

Static versus Dynamic (One Time Only)

MFA is typically based on single passwords.  Traditional static passwords, while a potential solution for MFA, simply aren’t enough to protect against some of today’s threats. Keystroke logging tools, phishing attacks, eavesdropping, and even guessing can be used to easily crack static passwords.

One-time-passwords (OTPs)

One Time Passwords (aka tokens) offer greater protection, because the password (token) they generate is only valid for a single session or transaction.

Time-Based One-Time Password (TOTP) are regulated by the RFC6238;. This algorithm is actually not only used in Google’s Authenticator, but also in the Microsoft Verificator.

Here is the basic flow:

1. User Logs In to the web app using her ADFS credentials –>
2. On successful login, the user is prompted for a second factor (Please enter a 6 digit code). This code is generated by the .NET code (using, first, a randomly generated secret key and SHA1) and sent to Google QR generator – which presents a QR code to the user. As long as the user has a QR reader app, she can decode this QR code – and type it into the presented textbox as her second factor –>
3. Once the user enters the 6 digit code, she is no longer prompted with a QR code. This is truly a one-time code – the QR code is not presented to the user again, unless she fails to enter it within the allotted  30 seconds.
4. That’s it. Pretty straightforward and very secure.

creating and Persisting the OTP

The RFC states; “The keys SHOULD be randomly generated or derived using key derivation algorithms.  To  generate the 16-character secret key, we can use the random number generator support in either .NET or java.

Random random = new Random((int)DateTime.Now.Ticks & 0x0000FFFF);
      return new string((new char[secretKeyLength]).Select(c => c = allowedCharacters[random.Next(0, allowedCharacters.Length)]).ToArray());

With multiple ADFS servers in a farm, and the possibility these servers do not share state, we cannot use in-memory mechanisms to check if a generated code has been used previously. Using a Database to store the key will ensure that at all servers in the ADFS farm can access and check used keys.

Summary

There are several ways one can do MFA. However, most MFA schemes are based on single (static) passwords. These are not ideal – as phishing, keystroke logging etc. can figure these out easily. It is much more secure to have a throw-away password – an OTP in place of the static password. Using Google’s QR generator, one can send a QR code as a disguised second factor. Whether they use a virtual device (an app) or some hardware scanner to read this second factor is up to them.

Once the user types in this 6 digit QR code, they are effectively second-authenticated. Now , this QR code is meaningless – as long as the server has a way to store it and check for previously used keys.

The post Multifactor authentication appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.

The post Another Chrome FIRST–Privacy through Obscurity… appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.

Everything I wanted to detail about this vulnerability was already explained in this post.

The post Concatenated Queries at the Root of SQL Injection attacks appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.

  var scoreQuery = from student in students
                         from score in student.Scores
                            where score > 90
                            select new { Last = student.LastName, score };

This is the equivalent of:

SomeDupCollection<string, decimal> nameScore = new SomeDupCollection<string, float>();
foreach(Student curStudent in students)
{
   foreach(Score curScore in curStudent.scores)
   {
      if (curScore > 90)
      {
         nameScore.Add(curStudent.LastName, curScore);
      }
   }
}

The post Multiple FROM statements in a LINQ expression appeared first on Anuj Varma, Hands-On Technology Architect, Clean Air Activist.