The document outlines key practices for securing websites, focusing on DNS security, reducing application load, encrypting traffic, detecting automated traffic, and managing vulnerabilities. It emphasizes the importance of using reputable services, enabling two-factor authentication, and regularly updating software while also addressing the significance of proper traffic encryption and bot management. The document also provides actionable strategies such as caching, setting security headers, and monitoring external libraries to mitigate risks effectively.

2. How to Ensure You’re Launching the
Most Secure Website
Product Manager — Web Application Firewall
Cloudflare
@MichaelTremante
Michael Tremante

3. 3
Topics Covered — Agenda.
1. Securing DNS
2. Reducing Load on your Applications
3. Encrypting traffic
4. Detecting Automated Traffic
5. Staying up to date with patches
6. Locking down admin areas
7. Migrating Client Side Attacks

4. 1: Securing DNS

5. “
I just had to take the hypertext idea and
connect it to the TCP and DNS ideas and
— ta-da! — the World Wide Web.
- Tim Berners-Lee

6. 6
• Use a reputable registrar
• Enable two factor
• Ensure all domain contact handles
(owner, admin, billing etc.) Are
correct
• Track your DNS portfolio!
• Enable registry lock is possible
• Don’t forget about renewals...
The domain name records for both companies were modified to
redirect to different websites when people entered “lenovo.com”
and “google.com.vn.”
The changes were apparently made through Web Commerce
Communications, known as Webnic.cc, a Malaysian company that
registers domains names.
IDG News Service
Lenovo, Google websites hijacked by
DNS attacks.
Is your registrar
safe?
% whois codelocket.com | fgrep "Domain Status"
Domain Status: clientTransferProhibited
https://icann.org/epp#clientTransferProhibited
Domain Status: clienttransferprohibited
https://icann.org/epp#clienttransferprohibited

7. 7
• Don’t rely on the registries DNS
service without testing
• And avoid hosting unless
necessary!
• Can it withstand load?
• Enable dnssec
• Check global resolution
• Remove unused DNS records
Is your DNS
reliable?
Using a distributed DNS service is easy.
% dig DNSKEY codelocket.com +short
256 3 13 oJMRESz5E4gYzS/q6XDrvU1qMPYIjCWzJaOau8XNEZeqCYKD5ar0IRd8
KqXXFJkqmVfRvMGPmM1x8fGAa2XhSA==
257 3 13 mdsswUyr3DPW132mOi8V9xESWE8jTo0dxCjjnopKl+GqJxpVXckHAeF+
KkxLbxILfDLUT0rAK9iUzy1L53eKGQ==
% dig DS codelocket.com +short
2371 13 2 77A20A9911F75239B6C67A152759236408508952257046CF5DFC1A01 D346DE5D

8. 8
You can have a very good DNS setup with little cost

9. 2: Reducing Load
(not only safer, but faster!)

10. 10
• Separate dynamic from static -
ideally load any dynamic content
via AJAX or other method
• Cache locally and at the edge
• Use a full reverse proxy for
caching (in addition to separate
hostname)
• Better caching ⇒ better DDoS
protection
• Don’t over optimise but build with basic caching principles in
mind
• A low cache TTL on semi dynamic resources (e.g. a news front
page) is better than no TTL - pushes load to the CDN
• For web applications - you can aim to a 90%+ cache hit ratio
• Setting cache headers is a good time to review other common
security headers:
▪ X-Frame-Options
▪ Content-Security-Policy
▪ Strict-Transport-Security
▪ etc.
Cache, cache, cache!
Do you have a
caching
strategy?
% curl https://www.codelocket.com -Is | fgrep cache
cache-control: public, max-age=14400
pragma: no-cache
cf-cache-status: HIT

11. 11
Monitor and look for missed endpoints.

12. 12
My site is fully served from cache.

13. 3: Encrypting Traffic

14. 14
• All traffic should be encrypted
• If you are using a proxy, ensure
traffic to the origin is also
encrypted
• Setup redirects from 80 to 443 if
necessary
• Use HSTS
• Don’t manage certificates unless
you have proper resources to do it
• Aim to support TLS 1.2 or above
only
Strict-Transport-Security is a great tool to ensure only encrypted
connections are initiated to your site.
Note: once an HSTS headers is cached by the browser, you cannot
control it from the server!
Must haves.
SSL/TLS is
finally easy.
% curl https://www.codelocket.com -Is | fgrep strict
strict-transport-security: max-age=2592000; includeSubDomains

15. 15
I don’t manage my certificates — but I also encrypt to origin.

16. 16
Check setup.

17. 4: Detecting Automated Traffic

18. 18
Lots of bots out there...

19. 19
Most bot traffic is non verified

20. 20
• Not all bots are bad
• Credential stuffing, data hoarding,
sneaker bots are examples of bad
activity
• Block/challenge connections from
large hosting companies
• Increase challenges for checkout
flows, authentication pages etc.
• Counter attack if possible: serve
stale/fake content, set up honey
pot etc.
Verify the easy bots:
• Google by reverse DNS on IP;
• Bing by reverse DNS on client IP;
• etc.
Everything else - honeypot or block/challenge if necessary and if
possible!
Block the easy bots.
Can you handle
bots?

21. 21
The rest is hard.

22. 22
Protecting against the hard bots...

23. 5: Patching Vulnerabilities

24. 24

25. 25
Layer 7 attacks are very common!

26. 26
• Map your entire software stack,
not only application layer
• Sign up to vulnerability feeds (if
available) for your main
components (e.g. WordPress)
• Plan for worse case - can you
redirect/set up a temporary page
at short notice?
• After the fact: what forensics tools
do you have available?
• Set up alerts on events
There are free WAFs out there:
• ModSecurity for Apache plus
• OWASP Core Ruleset
Proxy based cloud WAFs (or dedicated appliances) will offer better
protection. Look for:
• Automated ruleset updates
• Ability to scale fast
• Review analytics and forensics tooling
Use a WAF.
Protection
against direct
attacks.
# These exclusions remedy false positives in a default WordPress install.
# The exclusions are only active if crs_exclusions_wordpress=1 is set.
# See rule 900130 in crs-setup.conf.example for instructions.
#
# Note that the WordPress comment field itself is currently NOT excluded
# from checking. The reason is that malicious content is regularly being
# posted to WordPress comment forms, and there have been various cases
# of XSS and even RCE vulnerabilities exploited by WordPress comments.

27. 6: Locking down admin areas

28. 28
• Map your users and only allow
access when and where relevant
• Blocking by IP is not the ideal
solution, but can still be effective
• Adopt complementary 2 factor
and other authentication methods
— these can be deployed as a
service nowadays
• If using a proxy, only allow traffic
from the proxy
Protect admin and other restricted areas. These are not alternatives to
proper application security and best practices bu:
• will stop many scanners outright
• may give you early alerting of suspicious activity
This does follow the old castle and moat approach - but remains effective
for many attack vectors
Simple rules may include:
• lockdown wp-admin
• lockdown your origin server to receive traffic from the proxy only
• do not allow POST requests on your application from non
authenticated users
• etc.
Simple rules are effective.
Reduce your
attack surface
area.

29. 29
Locking down
wp-admin

30. 7: Client Side Security

31. 31
Magecart (supply chain) attacks are very common.
August 2018
Attackers compromised modernizr-2.6.2.js, a self-hosted Javascript library. For the next
14 days, the infected script exfiltrated payment details from British Airway’s checkout
page. The attackers preserved the original script functionality to avoid detection.
February 2018
Attackers targeted Inbenta, a chatbot company Ticketmaster used. The code, which was
present throughout the site, stole login details and payment information for at least 4
months.
July 2020
Attackers noticed that a Twilio SDK, taskrouter.min.js, was stored in an S3 bucket with
public read / write access. They edited the code to load in a malvertising URL, which was
active for 8 hours before discovery.

32. 32
Just when I was
preparing the slides….

33. 33
• Map external libraries and
applications you might be using
• Check they are maintained
properly
• Can you host some of them
directly?
• When were they last updated?
For web application dependencies (third party JavaScript libraries) there are
a few “easy” wins:
• use SRI hashes - they are simple to generate
• ensures that the browser won’t load the file if it changes
• if using a CDN, consider hosting libraries locally and serving from CDN -
reduces attack surface
• Set up CSP reporting
CSP blocking is more complex
• allow list based - needs maintenance
• if your app does not change often, do it!
• NOTE: not full browser support
Check your dependencies!
Where are you
loading
software from?
Content-Security-Policy: default-src 'self'; img-src *; media-src media1.com
media2.com; script-src userscripts.example.com

34. mst@cloudflare.com
@MichaelTremante
Thank you.
Michael Tremante