Because server-side scripts are executed on the Web server, it is important that the code doesn't have errors that would keep the page from displaying properly, or not displaying at all. If the script lacked code to handle errors, the Web site may respond to the error by not displaying the contents of the page.This could occur when the script tries to access variables or a database that didn't exist, or any number of other errors. Similarly, a perpetual loop in the code (where the same code is run over and over again without exiting) would prevent the script from running as expected, and prevent the page from loading until the Web server timed out and ceased execution of the script. By failing to include error handling, scripts can prevent a user from accessing Web pages, and in the case of a site's default page, may prevent users from accessing the site at all.
Preventing problems with scripts, applets, and other components that are included on a site is not impossible if precautions are taken beforehand. First, network administrators should not include components that they do not fully understand or trust. If they are not certain what a particular script is doing in a line of code, they should not add it to a page. Similarly, they should use applets and ActiveX components that make their source code available. If an administrator has a particular applet or component that they want to use but do not have the code available, they must ensure that it was created by a trusted source. For example, a number of companies such as Microsoft provide code samples on their site, which can be used safely and successfully on a site.
Code should be checked for any flaws, because administrators do not want end users to be the first to identify them. A common method for testing code is to upload the Web page and component to the site, but do not link the page to any other pages.This will keep users who are not aware of the page from accessing it.Then you can test it live on the Web, with minimal risk that end users will access it before you're sure the code is good. However, when using this method, you should be aware that there are tools such as Sam Spade (www.samspade.org) that can be used to crawl your Web site to look for unlinked pages. In addition to this, spiders may make the orphan Web page containing your test code available in a search engine. A spider (also known as a crawler) is a program that searches sites for Web pages, adding the URL and other information on pages to a database used by search engines like Google.Without ever knowing it, an orphan Web page used to test code could be returned in the results of a search engine, allowing anyone to access it. If you test a Web page in this manner, you should remove it from the site as soon as you've finished testing.
The best (and significantly more expensive) method is to use a test server, which is a computer that is configured the same as the Web server but separated from the rest of the network.With a test server, if damage is done to a site, the real site will be unaffected. After this is done, it is wise to access the site using the user account that will normally be used to view the applet, component, or script. For example, if the site is to be used by everyone, view it using the anonymous user account.This will allow the administrator to effectively test for problems.
An exploit that hackers can use to their advantage involves scripts and programs that trust user input. For example, a guest book or other online program that takes user input could be used to have a Server Side Include (SSI) command run and possibly damage a site. As we'll see later in this tutorial, CGI programs written in Perl can be used to run batch files, while scripting languages can also be used to run shell functions.With a properly written and executed script, the cmd.exe function could be used to run other programs on a Windows system.
For best security, administrators should write programs and scripts so that input passed from a client is not trusted.Tools such as Telnet or other programs available on the Internet can be used to simulate requests from Web browsers. If input is trusted, a hacker can pass various commands to the server through the applet or component.
As discussed in a previous section, considerable information may be found in Web pages. Because scripts can be embedded directly into the Web page, the script can be displayed along with the HTML by viewing the source code.This option is available through most browsers, and may be used to reveal information that the administrator did not want made public. Comments in the code may identify who wrote the code and contact information, while lines of code may reveal the hierarchy of the server (including paths to specific directories), or any number of tidbits that can be collected and used by hackers. In some cases, passwords and usernames may even be found in the code of an HTML document. If the wrong person were to view this information, it might open the system up to attack.
To protect a system and network, the administrator should ensure that permissions are correctly set and use other security methods available through the OS on which the Web server is running. For example, the NTFS file system on Windows OSes support access control lists (ACLs), which can be configured to control who is allowed to execute a script. By controlling access to pages using scripts, the network is better protected from hackers attempting to access this information.
In this tutorial:
- Web Based Services Security
- Web Security
- Managing Access Control
- Handling Directory and Data Structures
- Eliminating Scripting Vulnerabilities
- Logging Activity
- Finding Rogue Web Servers
- Stopping Browser Exploits
- Web Spoofing
- Web Server Exploits
- SSL and HTTP/S
- Instant Messaging
- Text Messaging and Short Message Service (SMS)
- Web-based Vulnerabilities
- Dangers Associated with Using ActiveX
- Protection at the Network Level
- Programming Secure Scripts
- Understanding Code Signing
- Buffer Overflows
- Making Browsers and E-mail Clients More Secure
- Securing Web Browser Software
- Resulting from Weak CGI Scripts
- FTP Security
- Secure Copy
- FTP Sharing and Vulnerabilities
- Directory Services and LDAP Security
- Securing LDAP