JavaScript
JavaScript is different from ActiveX and Java, in that it is not compiled into a program. Despite this, JavaScript uses some of the same syntax and functions as Java. JavaScript is not a full-fledged programming language (as Java is). It cannot create standalone applications; instead, the script typically is part of an HTML document, using the <SCRIPT> tag to indicate where the code begins and to indicate where it ends. When a user accesses an HTML document with JavaScript in it, the code is run through an interpreter.This is slower than if the program were already compiled into a language that the machine can understand. For this reason, JavaScript is slower than Java applets.There are both client-side and server-side versions of JavaScript.
Although JavaScript is different from ActiveX and Java in that it is a scripting language, it is still possible that a hacker may use a script to acquire information about a site or use code to attack a site or client computer. However, JavaScript is generally less likely to cause crashes than Java applets.An important part of scripting languages like JavaScript and VBScript is that they can run on the clientside (i.e., on a browser visiting a site) or the server-side (i.e., the Web site itself ). Server-side scripting allows Web pages to provide enhanced features and functionality, such as reading and writing to databases, running other programs on the server, or other operations that couldn't be performed using client-side scripting. Running scripts on the server as opposed to the client also has other benefits. Because the script is executed on the server before any content is provided to the browser, the script is processed and the results are provided faster than if they ran on the client-side.
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.
Note: As we've mentioned in this tutorial, another embedded scripting language that you can use in HTML documents is VBScript. As the name suggests, the syntax of the language looks very similar to Visual Basic, much like JavaScript resembles Java. It offers approximately the same functionality as JavaScript in terms of interaction with a Web page, but a major difference is that VBScript can interact with ActiveX controls that a user has installed. VBScript is often seen in Active Server Pages (ASP), as well as in client-side scripts.
Preventing Problems with Java, JavaScript, and ActiveX
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.
NOTE: The code for a Java applet resides in a separate file, whereas the script for a JavaScript is embedded in the HMTL document, and anyone can see it (or copy it) by using the View Source function in the browser.
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.
Because of the possible damage a Java applet, JavaScript, or ActiveX component can do to a network in terms of threatening security or attacking machines, many companies filter out applets completely. Firewalls can be configured to filter out applets, scripts, and components so that they are removed from an HTML document that is returned to a computer on the internal network.
Preventing such elements from ever being displayed will cause the Web page to appear differently from the way its author intended, but any content that is passed through the firewall will be more secure. On the client side, many browsers can also be configured to filter content. Changing the settings on a Web browser can prevent applets and other programs from being loaded into memory on a client computer.The user accessing the Internet using the browser is provided with the HTML content, but is not presented with any of these programmed features. Remember that although JavaScripts are not compiled programs, they can still be used to attack a user's machine. Because JavaScript provides similar functionality to Java, it can be used to gather information or perform unwanted actions on a user's machine. For this reason, administrators should take care in the scripts used on their site.
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
- HTTP/S
- Instant Messaging
- Text Messaging and Short Message Service (SMS)
- Web-based Vulnerabilities
- ActiveX
- Dangers Associated with Using ActiveX
- Protection at the Network Level
- JavaScript
- Programming Secure Scripts
- Understanding Code Signing
- Buffer Overflows
- Making Browsers and E-mail Clients More Secure
- Securing Web Browser Software
- CGI
- Resulting from Weak CGI Scripts
- FTP Security
- Secure Copy
- FTP Sharing and Vulnerabilities
- Directory Services and LDAP Security
- LDAP
- Securing LDAP