CloudInsidr

Cyber security, infotech

  • Subscribe!
  • Privacy Policy
  • Legal
  • Contact Us

Join us on Twitter: @CloudInsidr

Follow us on Twitter: @cloudinsidr
  • news & alerts
    • events
    • industry analysis
    • industry gossip
    • people
  • cloud, edge & co.
    • AWS
    • administration & orchestration
      • web servers in the cloud
      • mail servers
      • databases
  • cybersec & warfare
    • encryption
  • blockchain
Home cybersecurity and cyber warfare How to set up Report URI to prevent code injection attacks
How to set up Report URI to prevent code injection attacks

Cloud Insidr 2017-11-26 Leave a Comment

How to set up Report URI to prevent code injection attacks

A web service called Report URI can be a great help in creating an HTTP security policy that will protect your web application without compromising its functionality. Here is how to set it up to bolster your defenses against code injection attacks.

Code injection attacks pose a massive danger to any web application that’s exposed to the world. It literally takes minutes after a domain registration for the evildoers to come sniffing around. Chance are, they will keep coming back until the day they break in to vandalize your web application, hijack a user session or steal data some other way. By setting HTTP Security Headers, you can reasonably prevent code injection attacks in most cases (for more, read: Fixing your Web Server’s Security Headers: From Hall of Shame to Hall of Fame). A Content Security Policy header can effectively suppress code injection attacks.

There is no better way to define your content security headers than by using Report URI. Here is how to set it up.

The service allows you to obtain an report-uri endpoint for use with the directive Content-Security-Policy-Report-Only to log security incidents that violate your security policy as a result of user interactions with your web application.

Step 1. Obtain an report-uri endpoint 

In your web browser, navigate to

https://report-uri.com/

Sign-in to your account and head over to the Setup section. From the list of report-uri endpoints, select the address titled Content-Security-Policy-Report-Only and copy it to your clipboard.

For debugging and testing your HTTP Content Security Policy header, use a report-uri endpoint of the type Content-Security-Policy-Report-Only
For debugging and testing, use a report-uri endpoint of the type Content-Security-Policy-Report-Only

Next, you will want to enter this address into your web server configuration for your domain, but before the service will start collecting information, you have to do one more thing: define the domains to collect reports for.

Step 2. Enter eligible domains to collect security incident reports for

Navigate to the Filters section. Enter all the domains you want to keep an eye on into the field “Sites to collect reports for”, without the scheme, separated by a space:

domain1.tld domain2.tld domain3.tld
Report URI: enter eligible domains to collect reports for
Report URI: enter eligible domains to collect reports for

The service Report URI is now ready to collect reports—but is your web server ready to ask user agents to submit them?

Step 3. Configure your web server to use the report-uri endpoint

Setting up your web server to use your report-uri endpoint involvs adding a directive to your web server configuration file (see How to Create a Content Security Policy to Protect Your Web Application against XSRF/CSRF/XFS, Clickjacking and Other Code Injection Attacks for details). After a brief delay, the reports of any incidents that violate your current polity should begin streaming in. You will find them in the CSP section of your Report URI account.

Create a Content Security Policy to Protect Your Web Application against XSRF/CSRF/XFS, Clickjacking and Other Code Injection Attacks

Step 4. Analyze Report-URI incidents

Don’t just allow the reports to roll in, you need to take action.

Here is an example of an attempted code injection attack on our sister site Digital Masters Magazine. Attackers attempted to collect data using a 1 px image; the attempt failed thanks to the Content Security Policy in place.

Script execution blocked thanks to a Content Security Policy
Script execution blocked thanks to a Content Security Policy

Filed Under: cybersecurity and cyber warfare, HTTP Security Headers

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Subscribe

SSL/TLS Certificate Square (250 x 250)

Pearson Education (InformIT)

SSL/TLS Certificate Medium Rectangle (300 x 250)

Recent Posts

  • Upgrading from CentOS 6 to CentOS 7 and Beyond?
  • How To Figure Out Who is Signing In To Dovecot to Send or Retrieve Email
  • OpenSSH 9.9 Introduces Enhanced Quantum-Resistant Algorithms
  • OpenSSL 3.3 Final Release is now live!
  • How to Activate HTTP/2 with TLS 1.3 Encryption in NGINX for Secure Connections without a Performance Penalty
  • Is AWS sucking your budget dry? Strip it down to the nitty-gritty (without breaking stuff)
  • How to attach and mount an NVMe EBS volume on EC2
  • SELinux security contexts: correcting SELinux labels on a file system
  • Intel gobbling up Israeli Tower Semiconductor, Stock Goes Through The Roof
  • NGINX on AWS EC2: setting up a web server from scratch on a domain of your choice
  • Log4j RCE and mitigation techniques
  • Set up logrotate for Postfix

Symantec

Categories

  • administration and orchestration
  • alerts
  • AWS
  • Bitcoin
  • cloud, edge and everything in between
  • cryptocurrencies
  • cybersecurity and cyber warfare
  • databases
  • DNS
  • encryption
  • events
  • FinTech and InsurTech
  • homeland security
  • HTTP Security Headers
  • industries
  • industry analysis
  • industry gossip
  • Java
  • Linux
  • mail servers
  • networking
  • news
  • NGINX
  • people
  • php-fpm
  • reviews
  • SELinux
  • tips and tricks
  • Uncategorized
  • web servers in the cloud

Tags

AMI AWS AWS EBS Azure certificate cipher suites cryptography cyber defense cybersecurity cyber security Diffie-Hellman DNS DNS over HTTPS Dovecot EBS EC2 email encryption Fedora HTTP/2 HTTPS IBM letsencrypt Linux logs MariaDB MFA MySQL NGINX OpenSSL permissions php-fpm PHP 7 postfix RegEx Route 53 RSA SELinux SQL SSH SSL TLS TLS 1.3 TLS vulnerabilities WordPress

Archives

  • January 2025
  • November 2024
  • October 2024
  • May 2024
  • January 2023
  • March 2022
  • February 2022
  • December 2021
  • December 2020
  • November 2020
  • September 2020
  • January 2020
  • November 2019
  • August 2019
  • July 2019
  • April 2019
  • December 2018
  • October 2018
  • September 2018
  • August 2018
  • June 2018
  • May 2018
  • April 2018
  • February 2018
  • December 2017
  • November 2017
  • October 2017
  • August 2017
  • April 2017
  • February 2017
  • January 2017
  • November 2016
  • September 2016
  • August 2016
  • July 2016
  • March 2016
  • February 2016
  • January 2016
  • December 2015
  • November 2015
  • October 2015
  • September 2015
  • July 2015
  • February 2015

Recent Comments

    Wicked fast Networking (With a Government Clearance to Boot)

    ©2022 CybrAnalytiqa OÜ

    • Content purchasing and syndication