Debug classic asp application hosted on IIS with Visual Studio

Some non .Net Applications like the ones written in classic ASP are required to be debugged in Visual Studio. Since these are not hosted on IIS Express, but on IIS, you need to identify the worker process running your machine or the Server and attach the w3wp.exe with the Debug tool in Visual Studio.

Enable Debugging under IIS classic ASP section as shown below:

Under the Debug menu in Visual Studio, select “Attach to Process”:

There may be multiple worker processes running on the machine depending on how many applications are running under IIS. Match the right one with the correct ProcessID.

Add the debug points in your Asp file and hit the required Page in the browser.

Test emails on Server with SMTP

You can check whether the port is open on a Server by using tcping.exe which you can download online. Tcping can also be similarly used to check other ports on a Server.

Open Powershell or Command prompt in Admin mode and then type the following command:

tcping smtp.some.domain 25

Port 25 is usually the default port for SMTP communication between mail servers.

You can also telnet to test out this port. Telnet should be enabled on your machine.

telnet smtp.some.domain 25

You can send a test email using Powershell using the below command:

Send-MailMessage -From 'Test User1 <test.user1@test.com>' -To 'Test User <test.user2@test.com>' -Subject 'Test mail' -SmtpServer 'smtp.some.domain'

App Pool set idle time out IIS Server

When it comes to managing your website traffic, one of the things to consider is the availability of your website.

IIS has a idle time-out property that is by default set to 20 minutes. This means that if no request comes for your site for 20 minutes of inactivity, IIS would kill the worker process to free-up resources. This means the memory utilised by loading of classes, session etc. This can be helpful when multiple websites may be hosted on the Server and is resource crunched.

You’ll find the below settings under the AppPool advanced settings:

So, when the next request comes to your site to access something e.g. Login page, IIS Server would again need to initialize the Worker process and load the required resources to serve that request. The first request will be slow to respond to the user because of all the initialization time required. You need to think in these terms that how much traffic usually comes to your site. If your website requires high availability, then you should consider setting the idle time-out to 0 in the App Pool settings. Or if high availability isn’t a concern, you can think for how many minutes you’d usually require your application to be available depending on the traffic.

There have been studies regarding the make or break for websites because of their initial load time. So, please be careful about this setting. Internet facing websites usually require high availability. For Intranet websites, you can think of some number of minutes based on the usage.

Customize Logging fields in IIS for hosted website

Open IIS Manager on your Web Server and Select the Website for which you want to customize your logging fields. The changes can also be done at the Server level but that depends on the requirement.

Double-click on Logging icon.

Click on Select fields to select or remove any fields that you want in your IIS logs.

To add any custom field, click on the Add Field button as shown below and add the required header. The below example shows how you can get the Client IP information from the X-Forwarded-For Header (XFF) when the Website is hosted on a Server in a Load Balanced environment. The source of this information is in the Request header. The new log file will have an “_x” suffix to it’s name after modification.

The Logs directory shown above is where your Log files are saved. To identify the file name, check the Website ID under Sites on the left pane.
The Log file name format will be “W3SVC<ID>”.

Click on Apply on the Actions Pane on the right to apply the changes.

TELNET to test connection to POP3/IMAP

First, make sure TELNET is installed on your machine else you’ll get error. You can install TELNET through Add or Remove feature on Windows.
You can use TELNET via a command prompt to confirm.

For IMAP check port 143 and if using SSL then check port 993.

For POP3 check port 110 and if using SSL then check port 995.

Test POP3 connection:

  • Start a command prompt
  • Enter TELNET {webserver} port e.g. TELNET exchangesrvr01 995
  • Enter USER {login} e.g. USER testemail@mycomp.com
  • Enter PASS {password} e.g. PASS secret
  • Enter LIST to show the mailbox
  • Enter QUIT to Exit

At each stage you should receive an OK message. If there is an issue at any stage you will receive an error

Test IMAP connection:

  • Start a command prompt
  • Enter TELNET {webserver} port e.g. TELNET exchangesrvr01 143
  • Enter . LOGIN {login} {password} e.g. LOGIN testemail@mycomp.com secret
  • Enter . LIST “” “*” to show the mailbox
  • Press CTRL + ] and then QUIT to Exit

At each stage you should receive an OK message. If there is an issue at any stage you will receive an error.

Add Strict-Transport-Security (HSTS) response header to IIS hosted site

The HTTP protocol by itself is clear text, meaning that any data that is
transmitted via HTTP can be captured and the contents viewed. To keep data private and prevent it from being intercepted, HTTP is often tunnelled through either Secure Sockets Layer (SSL) or Transport Layer Security (TLS). When either of these encryption standards are used, it is referred to as HTTPS.

HTTP Strict Transport Security (HSTS) is an optional response header that can be configured on the server to instruct the browser to only communicate via HTTPS. This will be enforced by the browser even if the user requests a HTTP resource on the same server.

Cyber-criminals will often attempt to compromise sensitive information passed from the client to the server using HTTP. This can be conducted via various Man-in-The-Middle (MiTM) attacks or through network packet captures.

Security Scanners would recommend to using adding a response header HTTP Strict-Transport-Security or HSTS when the application is using Https.

Depending on the framework being used the implementation methods will vary, however it is advised that the Strict-Transport-Security header be configured on the server. One of the options for this header is max-age, which is a representation (in milliseconds) determining the time in which the client’s browser will adhere to the header policy. The browser will memorize the HSTS policy for the period specified in max-age directive.
Within this period, if an user tries to visit the same website but types http:// or omits the scheme at all, the browser will automatically turn the insecure link to the secure one (https://) and make an HTTPS connection to the server. Depending on the environment and the application this time period could be from as low as minutes to as long as days.

Enabling includeSubDomains attribute of the element of the root domain further enhances the coverage of the HSTS policy to all its subdomains.
HSTS has a separate mechanism to preload a list of registered domains to the browser out of the box.

It is also usually recommended to redirect all http traffic to https. I’ve written another post on how to do that.

To add the HSTS Header, follow the steps below:

  1. Open IIS manager.
  2. Select your site.
  3. Open HTTP Response Headers option.
  4. Click on Add in the Actions section.
  5. In the Add Custom HTTP Response Header dialog, add the following values:
    Name: Strict-Transport-Security
    Value: max-age=31536000; includeSubDomains; preload

Or directly in web.config as below under system.webServer:

<httpProtocol>
	<customHeaders>
		<add name="Strict-Transport-Security" value="max-age=31536000; includeSubDomains; preload" />
	</customHeaders>
</httpProtocol>

Set Project Build Order in Visual Studio

In order to set the Build order for your Solution, right-click on the Solution in Solution Explorer and Select Project Build Order:

Your Project Dependencies should be set correctly which is used to determine the Build order by Visual Studio.

The image below shows the Project references added in the Business layer to determine that the DTO and Persistence Projects should be built first before the Business layer Project.

The Project Build order will make sure the required dlls are available for the Api to compile correctly.

Now give your car batteries a good re-conditioning they need. Click here to know more.

Join Armoney for best Cryptocurrency trading experience. Trade from anywhere, anytime!

Remove unwanted response headers from IIS hosted site

You may receive an e-mail from your Security team after a scan, that your Web application exposing certain Response Headers that might get exploited by attackers to gain unauthorized access to the System.
While it may not always be necessary to mitigate these kind of vulnerabilities, you still have to weigh the options. This might be true even for say, a Reactjs app hosted on IIS.

If you do need to remove certain Response Headers like Server, X-AspNet-version and X-Powered-By, these can be taken care of at the IIS Server level or in web.config file.

We will firstly use the URL rewrite option which requires to be installed on IIS Server if not already present. You can download the installer here.

For the Server and X-Powered-By Response Headers, create Server variables as under URL Rewrite option as shown below:

Set the variable names as RESPONSE_SERVER and RESPONSE_X-POWERED-BY respectively.

Next create outbound rules using URL Re-write in IIS specifically for the Website. If you create these rules at the Server level, it’ll be applied to all Websites.

With Pre-condition set to None, make the below configuration using URL re-write in the Outbound rule. The same configuration requires to be done for RESPONSE_X-POWERED-BY server variable.

You can then test these Response Headers values should come as blank in the Dev Tools of your Browser.

For the X-AspNet-version Response Header, make the below entry in your Web.Config file. This will remove the Response Header altogether.

Add the following line in your web.config in the <system.Web> section:
<httpRuntime enableVersionHeader="false" />

Handle client side routes with IIS on Page refresh React App

When trying to handle Client side routing for your React App hosted on IIS say using react-router-dom, you might need to handle situations where users access specific sections of your App like http://testapp/courses. Users might even save these URLs in their favorites and try to access them later.

This problem is not known while debugging the App in localhost until you host the App on an IIS Server. Since your React App is a Single Page Application (SPA), the Server is unaware of any static files like courses and will give 404 error. To solve this, send all your requests back to IIS with URL rewrite to the index.html static file and let the React App handle the routing.

First install the URL Rewrite module on the IIS Server. Then create a web.config file for your App or create a new one with code as shown below:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
		<rewrite>
		  <rules>
			<rule name="ReactRouter Routes" stopProcessing="true">
			  <match url=".*" />
			  <conditions logicalGrouping="MatchAll">
				<add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
			  </conditions>
			  <action type="Rewrite" url="index.html" />
			</rule>

		  </rules>
		</rewrite>
    </system.webServer>
</configuration>

This should work well for your App when the user tries to access a Client side route and refresh the page or when trying to access the route later.

Serve static json files on IIS hosted React App

When you have a React App hosted on IIS Server, you might need to access the static json files in your application for various purposes like json translations etc.

When you try to access these static files directly in browser or through code e.g. http://app/translation.json, you’ll get a 404 File Not Found error because the MIME type is not set by default in IIS. This is true for any other static file like woff files for fonts.

Under your Web.config file configuration section, place the below sample code within system.webServer tags.

<staticContent>
		<mimeMap fileExtension=".woff" mimeType="application/octet-stream" />
		<mimeMap fileExtension=".json" mimeType="application/json" />
	</staticContent>

The Web.config file is not available by default for a React App. You can either create one manually or make a change in the IIS Server Website configuration which will generate the Web.config file automatically and then you can add the above changes.