Newest KB Articles in Programming, error messages and sample code

Disabling .NET Core in a Sub-Directory

Thu, 01 Feb 2024 22:45:20 GMT

You can prevent .NET Core (when it's the root application) from intercepting requests in a sub-directory by removing its handler mapping in the sub-directory's web.config file:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.web> 
    <trust level="Full" /> 
  </system.web> 
<system.webServer>
  <handlers>
    <remove name="aspNetCore" />
  </handlers>
</system.webServer>
</configuration>

This is useful in scenarios where you want .NET Core to be the main (i.e. root) application but want to run to another application in a sub-directory (e.g. .NET Framework, PHP, etc.)

Issue with making an encrypted connection to SQL server from your application

Thu, 30 Mar 2023 23:00:19 GMT

Issue
Your application returns the following error when connecting to the SQL server with an encrypted connection from your application (Classic ASP, ASP.NET, .NET Core and PHP).

The certificate chain was issued by an authority that is not trusted.

Cause of Issue
This error happens because we are using a self-signed certificate on our SQL server for encrypted connection.

How to Resolve the Issue

For Classic ASP / ASP.NET / .NET Core applications, update your connection string as follows

"Data Source=DBSERVERNAME;Initial Catalog=YOURDBNAME;User ID=YOURUSERID;Password=YOURPASSWORD;Encrypt=yes;TrustServerCertificate=true"

For PHP applications, modify the database connection information as follows

$connectionInfo = array( "Database"=>"YOURDBNAME", "UID"=>"YOURUSERID", "PWD"=>"YOURPASSWORD","Encrypt"=>true,"TrustServerCertificate"=>true);

Finally, Recycle your application pool within the control panel's Site Tools for the change to take effect.

Response header updates for PCI Compliance

Thu, 23 Jun 2022 19:16:17 GMT

Server and Scripting Response Headers

To meet PCI compliance requirements, four response headers often have to be removed: server, X-Powered-By, and in the case of a .NET (MVC) app, X-AspNet-Version and X-AspNetMvc-Version. The response headers can be viewed in a browser using dev tools like Chrome Developer Tools, the referenced headers being the last four in the screenshot below.

Removing the headers is fairly straight forward. With all but X-AspNetMvc-Version being removed via web.config update. In the case of X-AspNetMvc-Version, it is disabled in a project's global.asax(.cs) file.

Server

If a site is currently on IIS 8, it's recommended to have the site migrated to IIS 10 / Windows Server 2019 by Support. Where on IIS 10 the server header can be removed via the attribute removeServerHeader

<system.webServer>
  <security>
    <requestFiltering removeServerHeader="true" />
  </security>
</system.webServer>

Otherwise on IIS 8 the header response would be removed via the following rewrite rule for RESPONSE_Server. Unlike the attribute above, this method still returns a "Server" header, but the response is blank

<system.webServer>
  <rewrite>
    <outboundRules>
      <rule name="Remove RESPONSE_Server" >
        <match serverVariable="RESPONSE_Server" pattern=".+" />
        <action type="Rewrite" value="" />
      </rule>
    </outboundRules>
  </rewrite>
</system.webServer>

X-Powered-By

The X-Powered-By header is removed via the customHeaders element

<system.webServer>
  <httpProtocol>
    <customHeaders>
      <remove name="X-Powered-By" />
    </customHeaders>
  </httpProtocol>
</system.webServer>

X-AspNet-Version and X-AspNetMvc-Version

ASP.NET version is disabled using the enableVersionHeader attribute

<system.web>
  <httpRuntime enableVersionHeader="false" />
</system.web>

To remove X-AspNetMvc-Version, "MvcHandler.DisableMvcResponseHeader = true" is added to the Application_Start event of the global.asax or global.asax.cs as in the examples below

protected void Application_Start()
{
    MvcHandler.DisableMvcResponseHeader = true;
}

    Sub Application_Start()
        MvcHandler.DisableMvcResponseHeader = True
    End Sub

Example web.config and response

An example web.config removing the server, X-Powered-By and X-AspNet-Version would look like

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.web>
    <httpRuntime enableVersionHeader="false" />
  </system.web>
  <system.webServer>
    <security>
      <requestFiltering removeServerHeader="true" />
    </security>
    <httpProtocol>
      <customHeaders>
        <remove name="X-Powered-By" />
      </customHeaders>
    </httpProtocol>
  </system.webServer>
</configuration>

Then, along with the project update for MVC, the resulting response header would be

Additional Response Headers

Additional response headers maybe required, for example Content-Security-Policy (https://content-security-policy.com/), to set restrictions on how elements are loaded on the site. Because various headers may be required, a basic syntax example is

<httpProtocol>
  <customHeaders>
    <add name="headerName" value="setting or directive" />
  </customHeaders>
</httpProtocol>

As an example, and not explicitly a guide, nopCommerce has many of these customHeaders set by default, as seen below

<httpProtocol>
  <customHeaders>
    <add name="X-XSS-Protection" value="1; mode=block" />
    <add name="X-Frame-Options" value="SAMEORIGIN" />
    <add name="X-Content-Type-Options" value="nosniff" />
    <add name="Strict-Transport-Security" value="max-age=31536000; includeSubDomains" />
    <add name="Content-Security-Policy" value="default-src 'self'; connect-src *; font-src * data:; frame-src *; img-src * data:; media-src *; object-src *; script-src * 'unsafe-inline' 'unsafe-eval'; style-src * 'unsafe-inline';" />
    <add name="Referrer-Policy" value="same-origin" />
    <add name="Permissions-Policy" value="accelerometer=(), camera=(), geolocation=(), gyroscope=(), magnetometer=(), microphone=(), payment=*, usb=()" />
  </customHeaders>
</httpProtocol>

Note that setting these customHeaders can have unintended consequences on what elements are being loaded on the site. And extra care and review may be required versus the headers detailed in the first section of the article.

node.js

Wed, 02 Oct 2019 22:42:35 GMT

On IIS, node.js is handled by the iisnode module. To run a node.js script, a handler mapping will first have to be added to the site's web.config to process the .js script, or all .js scripts, using the iisnode module. To run a custom node.js version, see the Custom node.js Version section.

Handler Mapping

To have all .js scripts handled by the iisnode module, add module "iisnode" to the handlers element of the web.config as in the syntax example below:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <add name="iisnode" path="*.js" verb="*" modules="iisnode" />
    </handlers>
  </system.webServer>
</configuration>

If there are other files using the .js extension in the application, necessitating targeting specific files, update the handler path. For example, if the below ztest.js file were in the document root, the syntax would be:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <add name="ztest" path="ztest.js" verb="*" modules="iisnode" />
    </handlers>
  </system.webServer>
</configuration>

Note when adding a handler for more than one file, each will require a unique name.

Testing node.js

To test node.js, the syntax below may be copied, making sure to use the file extension .js. Or download and extract ztest.js; then upload the file to the site and visit the page in a browser.

  var http = require('http');

http.createServer(function (req, res) {
  res.writeHead(200, {'Content-Type': 'text/plain'});
  res.end('Hello world');
}).listen(process.env.PORT);

Custom node.js Version

Visit https://nodejs.org/en/download/releases/ and click the version number link under "Node.js" for the package download.

Then under "Binary Downloads" select the win x64 zip.

After downloading the zip, extract node.exe.

Then upload the extracted node.exe to an /App_Data directory on the site.

iisnode.yml

Create a new text file and name it "iisnode.yml". In that file add the following line: nodeProcessCommandLine: "server path to file"

For the example above where node.exe was placed in /App_Data, the syntax would be:

nodeProcessCommandLine: "E:\web\username\htdocs\app_data\node.exe"

To test the update, create a separate .js file and add the following syntax to display the version of node.js the site is using:

var http = require('http');
http.createServer(function(req,res) {
  res.writeHead(200, {'Content-Type': 'text/html'});
  res.end('Node.js ' + process.version);
}).listen(process.env.PORT);

Or download iisnode.zip for a sample iisnode.yml and test script. Edit iisnode.yml and replace "username" with the username used for logging into the DiscountASP Control Panel, then upload iisnode.yml (and the test script) to the document root.

Then viewing the test file through a browser should show the new node.js version.

Subdirectory and subdomain pointers with URL rewrite

Wed, 01 Aug 2018 22:40:01 GMT

To host multiple sites from one site hosting account, and barring conflicting rewrite rules, routing or a site built on the ASP.NET Core Framework, URL rewrite may be used to redirect domains and subdomains to subdirectories on an existing site. Syntax examples can be found below for each type of redirection. The rule(s) would be added to the web.config file in the document root of the site. For Core, see the last section.

Adding a Domain Pointer

DiscountASP Control Panel > Domain Pointers > Order Domain Pointer

For add-on pricing, please review: https://www.discountasp.net/asp.net-hosting/plan/#add-ons

Redirecting a domain to a subdirectory

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
 <system.webServer>
  <rewrite>
   <rules>
    <rule name="domain.com" stopProcessing="true">
     <match url=".*" />
     <conditions>
      <add input="{HTTP_HOST}" pattern="^(www.)?domain.com" />
      <add input="{PATH_INFO}" pattern="^/subdirectory/" negate="true" />
     </conditions>
     <action type="Rewrite" url="\subdirectory\{R:0}" />
    </rule>
   </rules>
  </rewrite>
 </system.webServer>
</configuration>

In the above syntax example, "domain.com" on lines 6 and 9 should be replaced by the domain pointer and "subdirectory" on lines 10 and 12 should be replaced by the subdirectory where the files have been uploaded.

Adding a Subdomain

A wildcard subdomain is added with the SSL and/or subdomain add-on. For add-on pricing, please review: https://www.discountasp.net/asp.net-hosting/plan/#add-ons

Redirecting a subdomain to a subdirectory

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
 <system.webServer>
  <rewrite>
   <rules>
    <rule name="subdomain.domain.com" stopProcessing="true">
     <match url=".*" />
     <conditions>
      <add input="{HTTP_HOST}" pattern="^subdomain.domain.com$" />
      <add input="{PATH_INFO}" pattern="^/subdirectory/" negate="true" />
     </conditions>
     <action type="Rewrite" url="\subdirectory\{R:0}" />
    </rule>
   </rules>
  </rewrite>
 </system.webServer>
</configuration>

In the above syntax example, "subdomain.domain.com" on lines 6 and 9 should be replaced by the applicable subdomain and "subdirectory" on lines 10 and 12 should be replaced by the subdirectory where the files have been uploaded.

If after adding either rule the subdirectory is being appended to the URL, you'll want to verify line 10 in the above syntax has been added to remove it.

ASP.NET Inheritance

Note that if the subdirectory is set as an application starting point and there is an ASP.NET application in the parent directory, the child application will inherit settings from the parent application. For more information about disabling inheritance, see: https://stackoverflow.com/a/5968658

ASP.NET Core

Microsoft.AspNetCore.Rewrite is middleware with support for URL rewrite rules. For an overview on using the middleware, see the microsoft.com article URL Rewriting Middleware in ASP.NET Core. To use URL rewrite rules like those above through a referenced xml file, see the IIS URL Rewrite Module rules section.

Checking / Updating Outbound TLS 1.2 Support

Wed, 27 Jun 2018 19:24:06 GMT

Due to changes in security, it may be necessary to update or migrate a site to use TLS 1.2 for outbound connections. Most notably for a payment gateway. For general information, including testing, find the applicable scripting section below (ASP.NET, Classic ASP, or PHP). If it's necessary to migrate the site to a newer version of Windows or you require assistance with reviewing TLS 1.2 support, please open a ticket with the Support Department.

Windows Server Version

The version of Windows Server, necessary to check for ASP.NET and Classic ASP support, can be ascertained by reviewing the Server Name in the DiscountASP Control Panel, then matching it against the key below. The Server Type field in the DiscountASP Control Panel will show whether the site is on Windows Server 2008, 2012, or 2016, but the key below will specify whether it's on 2008 R2 or 2012 R2.

Server key

Windows Version	Server Name
Windows 2008	web701 - web705, web707 - web709
Windows 2008 R2	web710 - web713
Windows 2012	web801 - web804
Windows 2012 R2	web800, web805 - web808
Windows 2016	web809 - web810
Windows 2019	web801h, web812
Windows 2022	web802h, web813 euweb01, euweb02, euhweb01

ASP.NET

The requirements for TLS 1.2 support when using ASP.NET are Windows Server 2012 R2 or 2016, ASP.NET Framework 4.5 or higher and bootstrapping code to set the TLS version.

If a site is hosted on older version of Windows, for migration assistance to Windows 2012 R2 or Windows 2016, please open a ticket with Support.

If a site is using an ASP.NET Framework older than 4.5 it will need to be updated. Note this is a project update rather than the ASP.NET Framework version set in the DiscountASP Control Panel.

To set the TLS version for an outbound connection, add the following to the script making the connection or the global.asax:

System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12

More information regarding the last update can be found after the link https://stackoverflow.com/q/28286086. Also note that the bootstrapping code would have to be updated if TLS requirements were to change in the future.

Classic ASP

For TLS 1.2 support through Classic ASP, the site should be on a Windows 2012 R2 or Windows 2016 server.

To test TLS 1.2, the script in zssl.zip may be used: zssl.zip

For migration assistance to Windows 2012 R2 or Windows 2016, please open a ticket with Support.

PHP / cURL

For PHP, TLS 1.2 support is dependent on the version of PHP set for the site. Which should be set to 5.5 or newer in the DiscountASP Control Panel.

DiscountASP Control Panel > IIS Tools > PHP Version (drop-down)

To test TLS 1.2, the script in zcurl.zip may be used: zcurl.zip

Installed .NET Core Frameworks

Wed, 24 Jan 2018 22:12:42 GMT

The listed versions of .NET Core support framework-dependent deployment on IIS 8 and IIS 10 web servers.

1.0
1.1
2.1
2.2
3.0
3.1
5.0
6.0
7.0
8.0
9.0
10.0

If you have been running your Core projects in self-contained mode, changing to framework-dependent often provides some level of performance increase as well as decrease memory usage.

Note Core Version 2.0.x has reached end of life and will be unavailable on newer web servers.

Reinstalling a clean version of WordPress

Thu, 05 Nov 2015 20:04:07 GMT

In this tutorial we will be reinstalling WordPress after it’s been compromised or “hacked.” The tutorial assumes three things: 1) The MySQL database your WordPress site was using wasn’t compromised, 2) The WordPress files were the only thing modified, and, 3) You have no other web applications installed in your site’s root directory.

Quick overview of the steps we’re about to take

Creating a two different directories locally on your computer.
- One containing your hacked WordPress site.
- The other containing your clean WordPress site.
Before changing anything we will be making a backup of your current WordPress site by downloading it via FTP. Yes, the current compromised WordPress site.
Downloading a clean copy of WordPress
Re-downloading your themes folder
Re-downloading your plugins folder
Copying your web.config and wp-config.php files from the old WordPress site to the root directory of your clean WordPress site
Restoring your images/upload files

Step 1 – Create two different directories on your computer

Create two different empty directories on your local computer.

Step 2 – Create a backup of your hacked WordPress Site

First you will need to establish an FTP connection to your site. Instructions on how to connect to your site via FTP can be found in this knowledge base article.

Once the FTP connection has been made, navigate to your local directory within FileZilla where you wish to place your backup.

Highlight all of the files and directories within your WordPress site and right click on Download to copy them to your local environment.

Important: We’re putting the files here for safe keeping, don’t open any of the files unless specified in this article.

Step 3 – Download a clean copy of WordPress

Go to WordPress Downloads and download the zip file.

Next you want to extract the clean files to the clean folder directory on your local computer.

Step 4 – Re-Download your theme files

Everyone uses a different theme for their WordPress site, so everyone’s case is going to be unique. If you remember where you downloaded your theme then go ahead and download it from the source and and skip to section Step 4 B.

Step 4a.

If you are unsure which theme you were using, navigate your \wp-content\themes directory in the hacked backup WordPress files.

WARNING: Don’t use the theme from the hacked WordPress site, it’s important to download a new copy from the source.

Within the \wp-content\themes\ directory you will see different directories. You will most likely see some of the default themes that come with WordPress:

Twentyfifteen
Twentyfourteen
Twentythirteen

But the other themes that are located in the \wp-content\themes\ directory will be the themes you downloaded for your WordPress site before it was compromised.

In my case I forgot the name of the theme I was using. From the list I see in the \wp-content\themes\ directory I can see that I was using the “rendition” theme.

My next step was to Google “rendition wordpress theme,” and I was able to locate the source of the theme.

Step 4b

Download and extract the clean theme files into the clean WordPress directory locally on your computer.

Once you have downloaded the zip copy of your theme locally on your computer, extract it to a location where you can simply copy and paste the clean theme into the \wp-content\themes\ directory within the clean copy of your WordPress file structure.

Step 5 Re-download your plugins

The plugins folder will be in the \wp-content\plugins directory.

If you don’t recall which plugins you had installed, you can always go into the hacked WordPress file structure to see which plugins were installed.

Make a list of the plugins you need to download and download them manually from the WordPress plugins site.

Extract the clean plugins you just downloaded into an empty file on your computer.

Copy and paste them into the clean copy of the WordPress site’s \wp-content\plugins directory.

Step 6 Copy web.config & wp-config.php file

We have to copy and paste the old web.config and wp-config.php file into the clean copy of the WordPress site’s root directory.

The web.config file contains the URL Rewrite rules for your WordPress permalinks links to work correctly on the IIS server.

The wp-config.php file contains the settings needed to reestablish a MySQL database connection to the original MySQL database.

Go to the hacked WordPress site root directory where your wp-config.php file is located and open it in a text editor like Notepad. You want to check for malicious code that you don’t recognize. Basically, you just want to make sure your old wp-config.php file is clean. You can compare it against the sample wp-config.php file. If you’re not sure what it’s supposed to look like. You can always check the clean version by checking the Github sample page of the wp-config file.

Once you have confirmed it’s clean, you’re going to want to change the password for your MySQL database.

Log into Control Panel and change the password for your MySQL database within the MySQL Manage section:

Click Manage next to the MySQL database.

Click Update Password.

Next you’re going to need to update the following line in your wp-config file with the new password.

Look for:

define(‘DB_PASSWORD‘, ‘OLD_password_here‘);

Replace it with:

define(‘DB_PASSWORD‘, ‘New_Password_Here‘);

Save the wp-config.php file and place it into the root directory of your clean copy of WordPress.

Next you want to simply copy and paste your old web.config file from the compromised WordPress site to the root of the clean WordPress site. web.config is not a file targeted in the typical WordPress compromise, so it’s usually safe to use the old version. You may want to take a look at it in any case, just to make sure it hasn’t been altered.

Step 7 – Delete your old WordPress files and upload the clean WordPress site

Connect to your site via FTP and delete everything from the root of the site.

You want to make sure you have an empty root since you will be uploading a clean copy of your WordPress site.

Once your root directory is clean go ahead and upload the clean copy of the WordPress site located on your local computer to the root of the site.

Your site should work now. Visit the site to verify that you did everything correctly.

Step 8 – Restore your old image and upload files

The last step is restoring your image files from your old installation of WordPress to your clean WordPress site.

First, browse your site to make sure you don’t have any missing images. If you do find that some images aren’t displaying correctly, you can use Google Chrome’s Developer tools to troubleshoot. By using the network tab you can see which images are missing and which directory they need to be uploaded to.

Once you find the image that is missing in the copy of your hacked WordPress backup, you can upload each image one by one.

In the image above we can see where our missing image file will need to go into our file directory structure. Simply locate the missing file from your compromised site backup and upload it via FTP to your clean site.

Done!

An important next step is to make sure you update any outdated plugins and themes from within your WordPress admin section. You should also update the password for your WordPress admin user.

.htaccess files

Thu, 10 Sep 2015 21:24:42 GMT

An .htaccess file is used to override the web server's global configuration for the directory it is in, and any directories below it. .htaccess files are commonly used for things such as allowing per-directory access control (password protecting), or URL rewriting.

.htaccess files are only supported on Apache web servers. They are not supported on the Microsoft IIS servers at DiscountASP.NET and Everleap.

To password protect a folder or file, check out this knowledge base article.

405 Method Not Allowed error with PUT or DELETE Request on ASP.Net application

Thu, 16 Apr 2015 22:07:03 GMT

If your application uses .NET WebAPI, you may get a 405 Method Not Allowed error when you issue a PUT or DELETE request.

This error is caused because the WebDAV module intercepted the request.

To work around the issue, you can insert the following in the web.config file in the root directory of your site:

<system.webServer>    
  <modules>        
    <remove name="WebDAVModule" />    
  </modules>    
  <handlers>        
    <remove name="WebDAV" />    
  </handlers>
</system.webServer>

Note that once you apply this setting, WebDAV will no longer work.