Programming Secure Scripts
The previous section primarily looked at client-side programs and scripts, which run on the user's machine. This section looks at server-side programs and scripts, which run on the Web server rather than on the machine being used to browse a site. Server-side programs and scripts provide a variety of functions, including working with databases, searching a site for documents based on keywords, and providing other methods of exchanging information with users.
A benefit of server-side scripts is that the source code is hidden from the user.With client-side scripts, all scripts are visible to the user, who only has to view the source code through the browser. Although this is not an issue with some scripts, server-side scripts should be used when the script contains confidential information. For example, if a Web application retrieves data from a SQL Server or an Access database, it is common for code to include the username and password required to connect to the database and access its data.The last thing the administrator wants to do is reveal to the world how information in a corporate database can be accessed.
The Common Gateway Interface (CGI) allows communication links between Internet applications and a Web server, allowing users to access programs over the Web.The process begins when a user requests a CGI script or program using their browser. For example, the user might fill out a form on a Web page and then submit it.The request for processing of the form is made to the Web server, which executes the script or application on the server. After the application has processed the input, the Web server returns output from the script or application to the browser.
PERL is another scripting language that uses an interpreter to execute various functions and commands. It is similar to the C programming language in its syntax. It is popular for Web-based applications, and is widely supported. Apache Web Server is a good example of this support, as it has plug-ins that will load PERL permanently into memory. By loading it into memory, the PERL scripts are executed faster.
As we've mentioned, Microsoft has offered an alternative to CGI and PERL in Active Server Pages (ASP)-HTML documents with scripts embedded into them.These scripts can be written in a number of languages, including JScript and VBScript, and may also include ActiveX Data Object program statements. A benefit of using ASP is that it can return output through HTML documents extremely quickly. It can provide a return of information faster than using CGI and PERL.
NOTE For more information about PERL, see the PERL FAQ on the www.perl.com Web site. For more information about CGI, see www.w3.org/CGI/. For more information about ASP, see www.w3schools.com/asp/default.asp.
Common to all of these methods is that the scripts and programs run on the server.This means attacks using these methods will often affect the server rather than the end user.Weaknesses and flaws can be used to exploit the script or program and access private information or damage the server.
Testing and auditing programs before going live with them is very important. In doing so, administrators may reveal a number of vulnerabilities or find problems, such as buffer overflows, which might have been missed if the code had been made available on the site. It is best to use a server dedicated to testing only.This server should have the same applications and configurations as the actual Web server and should not be connected to the production network.
NOTE: Any programs and scripts available on your site should be thoroughly tested before they are made available for use on the Web. Determine whether the script or program works properly by using it numerous times. If you are using a database, enter and retrieve multiple records. You should also consider having one or more members of your IT staff try the script or program themselves, because this will allow you to analyze the effectiveness of the program with fresh eyes. They may enter data in a different order or perform a task differently, causing unwanted results.
Code Signing: Solution or More Problems?
As we mentioned earlier in this tutorial, code signing addresses the need for users to trust the code they download and then load into their computer's memory. After all, without knowing who provided the software, or whether it was altered after being distributed, malicious code could be added to a component and used to attack a user's computer.
Digital certificates can be used to sign the code and to authenticate that the code has not been tampered with, and that it is indeed the identical file distributed by its creator.The digital certificate consists of a set of credentials for verifying identity and integrity.The certificate is issued by a certification authority and contains a name, serial number, expiration date, copy of the certificate holder's public key, and a digital signature belonging to the CA.The elements of the certificate are used to guarantee that the file is valid.
As with any process that depends on trust, code signing has its positive and negative aspects.The following sections discuss these issues and show how the process of code signing works.
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