While we constantly work to make the software as secure as possible, there are extra steps that system administrators must take to protect their data. We have divided the required actions into those on this page that need a 'system administrator', another page (here ) of ongoing security best practices for 'site administrators' and a page here of actions required at setup within the admin console. These should be a priority upon implementation:

• Rename the /admin folder to something unique to your site so it cannot be easily guessed. To do this:

• Log into your admin site, and change the AdminDir Setting to whatever you intend to name the folder. 
• Log out of the admin site, connect to your site through FTP, and rename the /admin folder to match the name that you set in the AdminDir Setting. 
• Restart the site

• Make sure that your web settings do not allow directory browsing or direct file retrieval! This should be standard security procedure for your host, but verify with them that the anonymous Internet user account does not have rights to browse files on the site.​

• Remove extraneous files that are not used by the software, such as .psd files, .sln files, .csproj or .vbproj files, etc. This operates on the same principle as turning off or removing unnecessary Windows services on servers to shrink the total attack surface, making your website more secure.​

• Be sure not to upload any of the folders that the original download may contain that are not necessary to run your site. Only the contents of the /web folder are needed on your production server. Source folders (ASPDNSFCore, ASPDNSFGateways, etc), the /db folder, and others should not exist on the live site. ​

• Follow the instructions here and here to configure custom errors and 404 redirects. These not only prevent exposure of sensitive path and database schema information, but also prevents customers from seeing ugly exception reports if a legitimate shopper does somehow encounter an error.​

• Use SSL. While it is technically possible to run a site without an SSL certificate installed (depending on the gateway), we strongly discourage it.  Internet shoppers are savvy about security, and know to look for the "lock" on their browser telling them the site is secure. Not using SSL is dangerous, breaks payment card industry (PCI) requirements, and shows your customers that you aren't concerned about their security.​

• Consider signing up for one of the 3rd-party tools like McAfee Secure.  Such services can scan your site daily to ensure that there are no known vulnerabilities on your online store.​

• Stay up to date with your software. This not only includes AspDotNetStorefront, but also third party components and operating system patches as well.​

• Set permissions properly on your website. It is important for your system administrator (most likely your hosting company) to understand the difference between the Anonymous Internet User Account and the ASP.NET Process account​. Never configure your site to run with administrative operating-system privileges.

• The ASP.NET Process account is a service account used by the web server to execute ASP.NET applications. This is the account AspDotNetStorefront uses to run. This account requires:​

• Read permissions on the entire site.​

• Write/Modify permissions to the root images folder​

• Write permissions on the OrderDownloads folder​

• Temporary Write/Modify permissions on the root folder for the web.config file only while encrypting/decrypting the web.config. Otherwise, Write permissions on the root folder should be disabled (set as Read only).​

• The Anonymous Internet User Account is used by IIS to display and execute static HTML files, images, scripts, and legacy web applications (such as classic ASP). This account requires the following:

• Read access to the site to display images, CSS, Javascript, and static HTML files.
• This account requires NO Write permissions on your site. Write permissions for the Anonymous Internet User account should be disabled.

 

 

It is the store owner's responsibility to ensure that these and other security precautions are taken. All sites should have documented and enforced password policies, apply Windows security patches as needed, maintain physical security of the server, etc. All sites need to maintain PCI compliance as well, as merchant gateways are constantly becoming more strict in their regulations.