Website security considerations

A website may have security issues in many aspects. Absolutely no security can be guaranteed by any means. A secure website can be created only by the cooperation of various parties.
The first concern is the security of the server. If the server itself is infiltrated and your website system is secure, it will not work.
The second is the security of FTP or remote management accounts. If someone cracks your FTP or remote management permissions, it means opening a window to others for fear, everything in the house is naturally taken at will.

The above issues related to system management are not mentioned here. The third aspect is Script Security. Aspect
Scripts are scripts run on servers such as ASP, JSP, and CGI on your website.CodeSuch as mobile systems and online forums.
Script code security issues mainly involve two aspects: SQL Injection and FSO permissions.
Most interactive websites have databases, and ASP code manages databases through SQL statements. Some variables in SQL statements are obtained through forms submitted by users. If the data submitted by forms is not filtered, attackers can construct special URLs and submit them to your system, or submit specially constructed strings in the form. As a result, SQL statements are not executed as expected.
Some netizens often submit some scan reports in the Forum, saying that the website has SQL injection vulnerabilities. For a complex system such as the ease of operation, we cannot say that developers will not omit the inspection and filtering of one or two forms of data. If such negligence exists, attackers willSource codeAs you can see, the website cannot withstand such attacks. In the early stages of power systems, such vulnerabilities were once discovered.

In a new version that is easy to use, the development team has made a lot of effort to prevent SQL injection. Almost all the data submitted through the form is divided into characters and numbers, use a dedicated function for processing. If the submitted data contains invalid characters, is replaced with a security character, or the submitted data is replaced with the default value. ToProgramIt has good fault tolerance. We have not responded to any data submission that contains invalid strings. For example, when you access showsource. the ASP Web page submits data such as channelid = % 3d, and the system changes it to channelid = 0, which is safe data, however, the message "the data you submitted is invalid" is not displayed. This is unnecessary for visitors.

This is because some of the more mentally retarded Vulnerability Scanners thought that the submitted channelid = % 3d was executed, so they told the user showsource. asp? High-risk vulnerability exists in channelid = % 3d. Technology
If you encounter a high-risk vulnerability reported by the scanner, you can contact our developers for confirmation. After confirmation by the developer that it does not exist, it certainly does not exist. You don't have to worry about it even if the scanner reports it. Attackers cannot exploit this vulnerability.

In addition to SQL injection, there is also a more serious security problem: Upload Trojans.
Because Upload components (usually ASP developers use one or more third-party Upload components or ASP classes) and webmaster's error settings (ASP or shtml files can be uploaded ), or other upload vulnerabilities may be exploited by attackers to upload backdoors. Once a vulnerability is uploaded, attackers obtain the permissions of the webmaster, or even exceed the permissions of the Webmaster (posing a security threat to the entire server ).
Over the past few years, ASP systems, including mobile networks, power, and mobility, have encountered upload vulnerabilities (especially last year's upload. inc upload. CER and other types of files ). But why is only some websites hacked after discovering such a large-scale vulnerability? Of course, it is not an attacker's hand or conscience, but some websites are set through servers to prevent losses caused by these vulnerabilities. For example:

Remove the "execute" permission for unnecessary directories and change it to "NONE", that is, the files under this directory can only be read and cannot be run. For example, except for the root directory, all the other directories in the Forum can only be read and the execution permission is disabled; the mobile system gives the root directory of the mobile root directory, the root directory of each channel, and the directory that contains ASP Web pages and ASP needs to be accessed from the browser to execute permissions, you can set "NONE" for others ". In particular, upload directories, such as uploadfiles and image directories must be set to read-only.
After this setting, even if the attacker finds the Upload Vulnerability and uploads the ASP Trojan to your uploadfiles directory, he cannot use the Trojan to do anything.
In addition, if your server uses the NTFS file system, it is also important to set permissions for the directory where the website files are located, you only need to grant the read and write permissions to iusr_your machine name. Do not grant full permissions to users like everyone \ guest. Users like IUSR _ machine name should be prohibited from granting permissions to non-web directories, in this way, you can avoid serious security problems caused by ASP Trojans uploaded to the server.
In addition, in the application configuration of IIS, removing unnecessary program ing is also a way to prevent attacks by attackers from uploading some special types of Trojans due to insufficient filtering. For example: