Build and configure a safer website
Suitable for Windows 2000 Advanced Server, Internet Information Services 5.0, SQL Server 2000, and .NET Framework's Best Security Program
December 2002 Author: Timothy Bollefer, Girish Chander, Jesper Johansson, Mike Kass, Erik Olson - Microsoft Corp.
Scott Stanfield, James Walters - Vertigo Software, Inc.
Summary: The Web site built by Microsoft .NET Framework, Microsoft Windows 2000 Advanced Server, Internet Information Services 5.0, and Microsoft SQL Server 2000, successfully opened 82,500 attacks in Eweek Openhack 4 competition, and won. This article describes the build and configuration methods of this solution, and provides the best solutions for software developers and system administrators to ensure their own solutions. (This article contains some links to English sites.)
table of Contents
Introduction Web Application Internet Information Service (IIS) 5.0 Windows 2000 Advanced Server Operating System IP Security Standard (IPSec) Policy Remote Management and Monitor SQL Server 2000 Password Summary More
Introduction
In October 2002, Eweek Labs held the 4th annual Openhack online security competition. This annual competition (this is Microsoft® third participation in this event) is designed to test the security of the company by exposing the system in a real-sin-sinister environment. EWeek provides a web application example to Microsoft and Oracle, requires that both parties use their own technologies to re-develop this application. Subsequently, Eweek invites computer users from all over the United States to destroy the security of the final site, and the winners can receive a certain amount of bonus. Acceptable destruction includes a spoken script attack, dynamic web page source code leak, destroying the web page, sending a malicious SQL command to the database, and stealing credit card data in the database used.
Microsoft uses Microsoft® .NET Framework to develop its applications. Microsoft® .NET Framework is a complete Windows component that supports building and running next-generation applications and XML Web services. This app uses Microsoft® Internet Information Services (IIS) 5.0 as a host and uses Microsoft® SQL ServerTM 2000 as its database. All servers are running on the Microsoft® Windows® 2000 Advanced Server operating system. (It is worth noting that if the Microsoft® Windows Server 2003 with IIS 6.0 is released during the competition, this version of the operating system is used. If you use Windows Server 2003, you can save the "lock" operation in the competition. Several steps in the system and web servers.)
The competition can be found in http://www.eweek.com/category2/1, 3960, 600431, 00.asp. All in all, Microsoft's solutions have allocated 82,500 attacks. Just as it appears in the first and second Openhack competition, Microsoft will win from the Openhack 4 competition. This article will introduce the various techniques used in the competition to illustrate the construction and configuration of this solution, and introduce these best programs to the developers and system administrators that ensure their own solution security. Web application
This app itself analog Eweek Excellent Awards Web site. In this site, users can register their company's products or services to participate in the award-winning selection. Users can set an account to select the input product or service, you can submit the credit card number to pay the registration fee, you can also obtain information about the award itself. Microsoft builds its solution using .NET Framework, .NET Framework is a complete Windows component that builds and runs applications and XML Web Service. Most developments are carried out around Framework's ASP.NET, ADO.NET, and encrypted class libraries. These three technologies are provided to build web-based applications, access, and use data, and encryption, decrypt, and ensure data. Sex.
Form authentication
The Microsoft® ASP.NET class provides several options for verifying user identity (ie, using some credentials, such as user names, and passwords to confirm the identity of the given user). These options include integrated Windows authentication, basic authentication, summary authentication, Microsoft® .NET Passport, and customer certificates. For each EWEEK request, the OpenHack solution selects a form-based or custom authentication.
When a user logs in via a form authentication, a encrypted cookie is created for tracking users throughout the site. (From a technical point of view, cookie is a plain text string generated by a web site that enters the user's web browser memory for identifying users of the browsing site.)
If the user requests a security page without logging in, the system redirects this user to the login page, all of which require the application's XML-based web.config file to configure. This file is automatically generated by Microsoft® Visual Studio® .NET (integrated development environment for building .NET Framework) to store the configuration of the ASP.NET web application.
In the root folder of the application, we add the following lines of code to the
This top-level configuration file is applied to all pages of this application. Then, create a subdirectory with the second Web.config file. This file is applied only to a few selected pages in the application to prevent access to without authentication (ie, anonymous users). The second.config file inherits the authentication information of the top. Config file.
In this way, use these two .config files, users who have not authenticated can only access homepage and other few pages, and users who have passed authenticated can also access those pages that require users to log in.
The login page itself contains a field for users to enter usernames and passwords, and returns them to the web server through a secure socket layer (SSL) to prevent certain users "stealing" the credentials transmitted in the network. After the user creates a new account, the web application will use the Triple DES algorithm to encrypt the new password (see the introduction of the storage confidential information section), and store it in the database with the username. When logging in later, the web application will encrypt the password entered on the login page, then compare the encrypted password stored in the database. If the two passwords match, the web application will use the System.Web.Security.FormSAuthentication class in the ASP.NET library to generate an encrypted cookie that contains the user's username and name. This cookie will return to the user and store it in the user's browser until it is timeout. Any request sent by the user later will contain this cookie. All transmissions involving cookie are performed using SSL to prevent the "playback" attack (ie, the attacker steals the cookie from the network, then use it counterfeit users to operate). It is highly recommended that you send sensitive information or credentials that can be used to access sensitive information or credentials via public networks.
Enter effectiveness verification
Openhack implements different levels, different types of validity validation in the application to ensure that the input other than the code (ie, user input) cannot change the operation of the application. Verifying Input Validity is a key to best security solution that helps prevent cache overflow, span-site script attacks, and other potential attempts to perform malicious code in the application context. Providing multi-layer protection (as you do this) is another important best security program called "layer flooring". Do the worst intended and assume that one or more layers of the solution may be destroyed, which is often important.
The first line of defense is the validity verification control provided by the ASP.NET (especially the RegularExpressionValidator class and the RequiredFieldValidator class), ensuring that all inputs needed and are valid data. Only characters for providing the required user are allowed, in this case, the character range is limited. For example, some fields only allow "[', /. 0-9a-za-z _] *", ie spaces, single quotes, commas, period, letters, and numbers. Other characters that can be used to send malicious scripts to the Web site are prohibited.
In addition to the text box, this application also accepts some inputs through the "Query String", and the query string is part of the dynamic URL that contains the parameters for generating the page. The data provided by the System.Text.RegularExpresss.Regex class is verified by the regular expression, as shown below:
Regex isnumber = new regex ("^ [0-9] $");
IF (ISNumber.match (InputData)) {
// use it
}
Else {
// Discard it}
Regular expressions are characters and syntax elements for matching text mode. In the OpenHack application, they are used to ensure that the query string content is correct and malicious.
All data accesses in this application are completed by parameterized stored procedures, which are developed using T-SQL language and run in the database according to defined in the database. The interaction with the database is limited to the stored procedure, which is usually a best solution. If there is no stored procedure, the SQL query must be dynamically constructed from a web application. If the web layer is destroyed, the attacker can insert malicious commands to the database query to retrieve, change, or delete data stored in the database. Using a stored procedure, the interaction of the web application to the database is limited to several specific stringent type parameters transmitted by the stored procedure. Whenever the developer uses the .NET Framework calls the stored procedure, the system checks the parameters sent to this stored procedure to ensure they are acceptable types of stored procedures (such as integer, 8 characters, etc.). This is another protective layer on Web layer validity verification, ensuring that all input data format is correct and cannot be constructed as an operable SQL statement.
Any data is html encoded before returning to the user. This is required to be implemented using the HTMLENCode method in the System.Web.httpserverutility class, as shown below.
SomeLabel.Text = Server.htmlencode (username);
HTML encoding helps prevent cross-site script attacks. Once an attacker disrupts the database, you can enter the script to the record, which will then return to the user and execute it in the browser. By HTML encoding, most script commands are automatically converted to harmless text.
Memory confidential information
Safely store confidential information (if database connection string for database login information) is important, which prevents attackers from accessing and using these confidential information to read, manipulate data, or reconfiguration solutions. Since this solution uses integrated Windows authentication to access the database, the value of the connection string has been significantly reduced for attackers, because the connection string only contains the location of the server and the database name, not specific specific Credentials (such as passwords).
By default, the database connection wizard in Visual Studio .NET will store the connection string as the attribute value in the "Code" file (this file contains the core logic of the application, which is different from the file defined by the user interface) .
This provides convenience to developer access strings. However, if the attacker is trying to log in to a physical computer containing the source code and .config file, it is possible to read the connection string and use it to access the database for malicious damage.
In a production environment, you usually recommend proper protection of the connection string and any other required credentials. A method of protecting credentials is the method used in OpenHack 4: encrypts the connection string, stores it in the registry, and uses the Access Control List (ACL) to ensure that only system administrators and ASPNET assist processes (IIS section Out of definition can access the registry key.
Using the Windows 2000 / XP Data Protection API (DPAPI) function CRYPTPROTECTA and CRYPTUNPROTECTDATA encrypts database connection string, using these two functions can encrypt confidential information without direct management (or store) Subsequent registration of these confidential information Entry.
Although the DPAPI is ideal for encrypted user or computer specific data, it is not a very effective way for encrypted information (such as credit card number and password) stored in the shared database. This is because the DPAPI function creates and internal storage encryption keys according to the local computer and / or user information. In a web domain scenario, the web server will use your own encryption key to prevent them to access the same encrypted data. Therefore, in order to demonstrate the method used in the Web field, a random Triple DES encryption key and an initialization vector are generated. This feature is provided with the TripleDes class in the .NET Framework's System.Security.cryptography. These keys are used to symmetrically encrypt passwords and credit card information stored in the database. In order to store the credit card information, a random first piece of an encryption is selected as the processing technology.
After generating a backup copy of the key, we use the DPAPI to encrypt it and store it in the registry, and then use the ACL to grant access to the system administrator and the ASPNET assist process. Encrypt the key to ensure that the data cannot be decrypted when the attacker actually positions and accesss the data first. This is another typical example of "layer floor fortification".
Internet Information Service (IIS) 5.0
In order to prevent the attacker attack web server itself, we make an appropriate changes to the Internet Information Services (IIS) 5.0 web server in Windows 2000 Advanced Server. First, all public security patches listed on the TechNet Web site are installed to ensure that there is the latest enhancement. When running any software, install the latest service packs and patches is a very critical security solution.
Then, the default Web site position on the disk is then changed from the default location C: / INETPUB / change to other volumes. Therefore, once the system is destroyed in some respects, the attacker will be difficult to navigate to this directory tree unless it does understand the actual location of this directory tree, that is, an attacker cannot be entered by input .. Access C: driver.
Next, run the IIS lock tool with a template that came with a static web server. This action deletes all other dynamic content types that are not used in this application. Reduce surface areas exposed to potential attackers in this way are often important. IS LOCKDOWN TOOL is available for free. It is a very good resource that all system administrators running IIS should use it.
At this point, we have installed .NET Framework Redistributable (it is required to run .NET Framework applications) ,. Net Framework Service Pack 2, the latest .NET Framework problem correction and MDAC 2.7 (components required for .NET Framework) ).
In this scenario, the application only uses dynamic files with .aspx extensions and several static content types for image and style sheets. Since other IIS application maps installed in the .NET Framework are not required, these extensions are restricted to 404.dll extensions included with the IIS lock tool. This is also to reduce the surface area exposed to the solution.
This app runs the ASP.NET code using the default local service account (ASPNET account) using low permissions. The principle of "minimum authority" is important for all managers, and never grants the accounts not absolutely needed. A lock solution is equivalent to reducing exposed surface areas in this way.
(The ASPNET account is created as a local account when installing .NET Framework redistributable, which belongs to the "User" group on the computer that creates the account. So it has all permissions related to this "User" group, and can be used in this user Any resource that has the right access to interact. In addition, it has full access to the Temporary ASNET Files directory and% windir% / TEMP by default, and read permissions to the Framework installation directory.) We will The ASPNET account is added to the local "Web Application Group" created by the IIS Locking tool to prevent processes running any authorized command line executable when they are attached.
We have modified the permissions of this user group and allow the user in this user group to run the .NET Framework C # compiler and resource converter (CSC.exe and Cvtres.exe) required by the user.
The IIS Locking tool is installed in Urlscan 2.5, which is an ISAPI filter that monitors and filter all input requests to the IIS web server based on rules such as query lengths and character sets. Configure URLSCAN to allow only extend sets used in the application and use it to block longer requests. This is another example of depth protection, which prevents an additional protective layer that is inserted into the malicious code via the user. Urlscan is provided free of charge in TechNet and IIS Locking Tools. Like the IIS lock tool mentioned earlier, Urlscan is a very good resource that all system administrators running IIS should use it.
We set appropriate permissions for the web content directory to grant the ASP.NET process to read access to the content file, grant anonymous user's appropriate read-only access to the provided content.
Only if a system account and a member of the system administrator group have access to the log directory of IIS and URLScan. Restrictions on log files are often necessary, which makes attackers to make changes to overwrite records or hide the useful information about the attacked.
Windows 2000 Advanced Server operating system
The server used in this competition all runs the WINDOWS 2000 Advanced Server operating system that is installed in Service Pack 3 (which is the latest service pack when the competition. All security patches published on the TechNet Web site since the release of the Service Pack 3 are also installed. The latest security patch is also a very important security solution for system administrators.
Installing these updates will be changed to some configurations to further enhance the integrity of the operating system level. First, all unnecessary operating system services are disabled, which is usually a best solution. By closing these services, the system resources can be released and the surface area exposed to the attacker can be reduced. A particular service that can be disable will vary with the needs of each solution. Messenger, Alerter, and Clipbook are just several examples of the service.
It is highly recommended that you read Windows 2000 Server Resource Kit to help determine unwanted services. The corresponding test is then performed to ensure that the application can work properly without these services. Finally, change these services to disabled to close them.
In the application, we also changed four registry settings to further enhance security in the app. We recommend all these as a best solution, as long as you don't need to disabled features.
Create a registry key: nolmhash (required, in Windows 2000, this is a keyword, and in Windows XP and Windows Server 2003, this is a value.) Location: HKLM / System / CurrentControlSet / Control / LSA Uses: Prevent the operating system stores the user password in the LM hash format. This format is only used to not support NTLM or Kerberos's Windows 3.11 client. The risk of creating and retaining this LM hashing is that if the attacker tries to decrypt the password stored in this format, you can repeat these passwords on other computers on the network. Create a registry value: NodeFaultExempt
Location: HKLM / System / CURRENTCONTROLSET / Services / IPSec Uses: By default, IPSec will allow the source port 88 to query the IPSec service to get information connected to the computer, regardless of which IPsec policy is used. By setting this value, in addition to the communication allowed by our IPSec filter (see an introduction to the IPSec policy section for details), you are not allowed to communicate any communication. Create a registry value: disableipsourceerouting
Location: HKLM / System / CURRENTCONTROLSET / Services / TCPIP / Parameters Purpose: Prevent TCP Packets from being explicitly determined to the final goal, and prevent it from requiring the server to determine the best route. This is a protective layer that prevents "human in the middle" attack (ie, the attacker is routed through its own server, and stealing the contents during packet transfer). Create a registry value: SYNATTACKPROTECT
Location: HKLM / System / CURRENTCONTROLSET / Services / TCPIP / Parameters Use: This registry key prevents the operating system from attacking a SYN-FLOOD by restricting resources assigned to incoming request. In other words, this will help prevent attacks from using SYN (ie synchronization) to reject service between clients and servers.
In addition, although there is no direct relationship with preventing attacks, we also enable several audit logs to override login and logout events, account management, policy changes, and system events. This helps us better monitor the server in the competition.
IP Security Standard (IPSec) Policy
Starting with Windows 2000, Microsoft has already supported the authentication and encryption of the INTERNET Protocol (IP) communication with the IP Security Standard (IPSec) (Extension of IPv4 Protocol). The following is shown in Figure 1 shows the default policy of the Server (Request Security Settings) Properties dialog. We specially created a strategy for the competition.
Figure 1: "Server (Request Security Settings) Properties dialog
The IPSec rule is configured in "Local Security Settings" of the Microsoft Management Console (MMC) management unit, as described above. These strategies have played a major role in enhancing and ensuring the security of the communication allowed by the OpenHack server. These rules enable us to enhance the best privilege from the following methods:
Requires all the communication required to run and manage applications in the IPSec policy of each system. Requires the communication between the system to authenticate the system. Communication for management (certificates) and encryption are required for communication. Refused applications or system management of all communications that are not explicitly allowed, including ICMP and IP communication ("Default Reject" rules).
IPSec rules have three main parts: identify filters for communication by IPSec, the filter to be taken when the filter is found, and the authentication mechanism for establishing security associations. If two systems to communicate do not have a rule that identifies the communication, there is no public authentication mechanism between the two, they will not be able to establish a connection. The first step in using the IPSec lock solution is to fully understand the communication path between different systems to establish an appropriate IPSec filter. The web server should be allowed to communicate with the SQL server database; the remote access server should allow the system administrator to use the virtual private network (VPN) to access the network management segment; the management server should grant the VPN client to create a Windows 2000 Terminal Services client session permissions ( To access applications running on the remote computer desktop and access and copy files to share permissions shared on the management server; all systems should allow the management server to generate management terminal service sessions for their private interface; Finally, all systems should be able to access management The specific file shared on the system. When the connection between the system is mapped by each port, we created an IPSec filter on each system.
The method of processing communication must then be determined because communication is identified by a filter on the system. For OpenHack 4, we define four operations that can be taken (called "Filter Actions):
Block communication. Allow communication. Authentication and signature - authenticate the communication source using the certificate and use the packet sign name to establish security associations. Authentication, signature, and encryption - use certificates to authenticate communication sources, establish security associations with encryption and packet signers.
Blocking rules is to discard the packet. This rule is the same as the "default reject" rule, which means "If we do not express communication, communication" is prohibited. " Allow rules to allow communication, without considering communication sources. This feature is used to allow public access to the web application.
Although the use of certificates to authenticate communication requires us to generate and distribute IPSec certificates from a public certificate authority (CA), it has significantly enhanced the ability of the system to communicate secure. It is worth noting that we use a separate CA. After granted all certificates, the CA will be removed from the network. If this CA is no longer needed, you must follow this method because it is another good way to reduce the surface area of the solution.
Use the IPSec certificate to ensure the identity of the source system and the target system, including the remote system administrator accessing the remote access server. By configuring policies to sign all transmissions with SHA1 hash, ensure that the packets will not be successfully modified by the attacker when passed between backend systems.
We use the MD5 encryption algorithm to encrypt the management server communication. Using this method, even if an attacker can destroy the security of an Internet system, it is impossible to steal the communication of a private network. This allows system administrators to securely connect to real-time Web sites for application updates.
IPSec uses a special rule with the highest priority to handle rules. Therefore, each system initially has two rules:
Block all IP communication. Block all ICMP communications.
Then, the rules are built for each system. Provide "authentication and signature" filter operations to the web server and database server; give "authentication, signature and encryption" filtering to communication with the management server; set the public access to the web site to allow access.
The logical connection of the OpenHack 4 application established using IPSec is shown below.
Figure 2: Logical connection using IPSec
Remote management and monitoring
Part of OpenHack 4 is to update the application during the competition. This feature is implemented by creating a VPN, a terminal service, and a restricted file sharing by using the Layer 2 Tunneling Protocol (L2TP).
Figure 3: L2TP for creating a VPN (Terminal Services) First, L2TP requires an IPSec certificate to establish a connection. We configure several remote system administrators with appropriate certificates. Then create an account that enables remote access to the remote system administrator.
To establish a VPN connection, the system administrator must install the IPSec certificate on the system and remote access account credentials. Briefly, the IPSec certificate embeds the certificate of the certificate to the certificate store of the local computer in an unsurable format. This means that this certificate will not be ported and used on other systems. In fact, we can ensure that the system administrator can only use the VPN client account in the allowable remote management workstation to minimize the management access to the solution.
After authenticating the L2TP session, the system administrator workstation will get the IP address on the management network. After establishing the VPN tunnel of the Management Network, the system administrator can open the terminal service session of the management server OHTS and can use the "Inbox" and "Outbox" file on the management server to discard the change of the change. Content or search file analysis. All systems are independent (ie, not a domain), so the shared access and terminal service sessions are configured to use the local accounts on the system by enhanced unambiguous passwords (see the password section). The sharing used is limited to only allow read operations for the "Outbox" and writes "inbox".
A large number of management work is conducted in the management server "Terminal Services" session. In this session, the system administrator will connect to the remote management terminal service session of any other system, fundamentally "nested" terminal service session. Then, you can connect to the "Inbox" and "Outbox" sharing on the management server, and discard or retrieve files according to the needs of the service. All communications that support these management functions require IPSEC, as described above.
SQL Server 2000
Openhack SQL Server 2000 Database is running on a private computer, this is a "layer floor fortification" measures. Even if the Web layer crashes, the database and all the information it contain will remain isolated and protected.
As mentioned above, our solution uses integrated Windows authentication to the database. This is a way to learn from because it does not need to develop and securely store passwords for accessing the database.
In order to ensure backward compatibility, Windows 2000 and Windows XP support several types of authentication protocols. Since only the computer that implements NTLMV2 authentication can access our database server, it is strongly recommended to change the LAN Manager authentication level to "NTLMV2". Note that NTLMV2 can also be supported using other configurations, Windows 95, Windows 98, and Windows NT Server 4.0 with Service Pack 4 and later. The system administrator minimizes the surface area exposed to the attacker by limiting the number of identity verification protocols supported.
Figure 4: Setting the LAN Manager Authentication Level
Using SQL Server, like WINDOWS, we need to carefully install, configure, and run the necessary services to reduce the database surface area that exposes the potential attacker. For OpenHack, we have not installed upgrade tools, debug symbols, copy support, online books, or DEV tool components.
This installation is performed on the NTFS partition because it provides additional ACL-based security protection for files and folders used by SQL Server. Next, it is usually the most critical step, which is to install SQL Server 2000 Service Pack 2 and all the latest patches.
The SQL Server installer can usually find the SQL Server installer in a computer for the service account for Localsystem. Although this is acceptable in a well-locked private network, it is acceptable, but because it is the management account on the base computer, it still has the permissions that exceeds the SQL Server service truly required. If the service account is required to access network resources (such as backing up to the network drive, when using log transfer or using copy support), it is best to select a low permissions domain account. However, if your environment does not need these features, you can select a local account of low permissions. In this competition, we used the local user account because it is not intended to use these features. We created a new NT local user account using the following settings:
Create a very powerful password (see the introduction of the password section for details). Remove the user to change its password. Delete "Terminal Services" access.
Once you have created a new user account, we use SQL Server Enterprise Manager to change the startup service account information, and force database services to run with this user.
Figure 5: Change Startup Service Account Information
In order to insist on running the ideology and best security schemes of the required services, we use the Services MMC management unit to stop the Distributed Transaction Coordinator (MSDTC) service, and set it to manually, so that the OpenHack database will not run transactions, the server itself Will you run a COM application. Here we see another advantage of running the database server on a private computer: more than the server running in parallel with other servers and servers, which has stronger reduction of the surrounding surface area.
It is also possible to further reduce the surface area by disabling SQL Server Agents and Microsoft Search Services, as our database solution does not require this feature.
Next, due to more reliability rather than security issues, we set up the properties of the Microsoft SQL Server service itself and change the recovery operation to restart the service after a fault. This is to minimize downtime when there is a fault.
Figure 6: Change the recovery operation to restart the service after the failure
Then we set up the Server Network utility and change the network properties from "Direct Client Broadcast" to "Hide SQL Server". Also deleted the "Named Pipe" protocol because we only need TCP / IP.
As part of this configuration, we returned to the previous configuration and set a very powerful password for the SA account. This approach is recommended even in Windows Authentication mode. If you are switched from the authentication mode from the authentication mode from the authentication mode through the Enterprise Manager tool or pass the registry, you want to ensure that the system is secure (even if the system administrator forgets to set the SA password) or use this method. In this approach, it is best to do the worst plan.
We change the default login audit setting to Failure. This will write all failed attempts of the SQL Server database to the error logs and event logs, which is very useful to identify the attack database.
We then remove the default Northwind and Pubs database to reduce the surface area exposed to the potential attack.
After all steps have created the Awards database used in the final solution. Then carefully check the list and stored procedures and ensure that the account associated with the application has only permissions to the stored procedure, and there is no permissions to the actual table. This allows us to control access to the stored procedure and limit the action to it, but do not worry about the special SQL query that is directly running directly. In addition, we have ensured that this account does not have any other privileges and permissions in SQL Server.
password
Make sure that the key step by any server security is to choose the long and complex password that will not be guessed. Ideally, an excellent password should include at least three groups in the following four sets of characters: lowercase A to z, uppercase A to z, numbers 0 to 9, and non-alphanumeric symbols (such as ">", "*", "&"Wait). In order to ensure safety as much as possible, the password should consist of each group of characters in the above four groups and characters using the Alt key. Use these character sets to create a password for at least eight characters in length, and minimize attackers to speculate on login credentials. This is the method used by each server in the OpenHack solution, but also the method we recommend to you. summary
Make sure that all steps taken by OpenHack Solutions are not applicable to each web solution. These steps do not represent all methods that developers and system administrators should take when ensuring the security of the solution. Each project is unique and requires developers and administrators to find potential attack factors and preventive measures. That is, OpenHack 4 indicates that the above recommendations are very valuable. Even if they cannot be applied directly to your solution, some key solutions should be extracted in order to apply in a form or another form when building security solutions:
Consider security issues in the original design. This includes development processes to adopt the latest service packs and patches. Always install the latest service packs and patches. Always use complex and unambiguous passwords. Turn off all unnecessary features to reduce the surface area exposed to the attacker. Adhere to the principle of "minimum authority". Never grant is not absolutely necessary. Predicting possible failures and always adopting "layer flooring" to reduce negative impacts. When using IIS, run the IIS lock tool and Urlscan. Verify all input data. Use the parameterized stored procedure instead of generating a dynamic query on the database.
