Internet Programming

Introduction

Over the last few years the scripting programming languages made a giant leap ahead. About ten years ago they were viewed as an axillar tools, not really suitable for general programming parse. Now they generate a tremendous amount of interest both in academic circles and in the software industry.

The execution speed and memory consumption of scripting languages vs. the traditional languages is studied in. Article presents a historical back- ground of the scripting languages. In a practical case of using the scripting languages in a commercial environment is presented. Finally, presents some trends for the future.

In this overview I first try to define what scripting languages are. Then a classification of the languages based on their application areas is presented. After that, the most popular of scripting languages are presented, and the peculiar features of each one are highlighted. The paper is concluded with the discussion on why scripting languages are important, and what their role is going to be in the future.

What are Scripting Languages?

The boundary between the scripting programming languages and the traditional ones is somewhat blurry. However, it is possible to highlight a few characteristics of scripting languages, that, when taken together, could serve as a definition:

• They are interpreted or byte code-interpreted and never compiled to native code • The memory handling is done by a garbage collector and not by a programmer. • They include high-level data types, such as lists, associative arrays and so on • The execution environment can be integrated with the program being written • The scripting programs (or simply, scripts) can access modules written in lower-level languages, such as C.

Not every scripting language has the whole set of these features? For example, shell scripts cannot access C modules. But it’s a scripting language nevertheless. The main idea behind the scripting languages is their dynamic nature, that allows treating data as a program and vice versa. The list of the scripting languages includes: shell, awk, Perl, TCL, Python, Java, Lisp and many others.

Server-Side Scripting Language

A script is really just another word for a program. It is just a set of instructions that take place automatically when you run the script (cause it to work). Some other words that you may have heard that mean essentially the same thing are macro, program, function or command. “Server-side” just means that the Web Crossing server rather than running a script on each user’s personal computer handles the control of the script. Web Crossing runs the scripts and sends standard HTML (web pages) to each user’s browser. All the end user’s browser has to worry about is displaying the results and does not have to worry about the underlying script used to generate the web pages.

3.1Example of Server-Side Scripting Language

3.1.1Net.Data

Net.Data is a server-side scripting engine that allows you to easily create dynamic documents using live data from a variety of sources such as relational and non-relational database management systems (DBMSs), including DB2® databases that can be accessed through DRDA®, files, and native applications written in programming languages such as RPG, Cobol, Java, C, C++, and REXX. Net.Data operates on scripts called macros, which contains a series of statements that are defined by the Net.Data macro language. These statements can include standard HTML (or XML, etc.) and language environment-specific statements (for example, SQL statements) as well as macro directives. These statements act as instructions to the Net.Data macro processor, telling it how to construct the dynamic page.

Net.Data interprets the statements to create dynamic Web pages with customized content based on input from the user, the current state of your databases, other data sources, existing business logic, and other factors that you design into your macro. The dynamic page that is generated can be rendered in a variety of formats. For example, HTML for browser clients, XML for browser and application clients, wireless markup language (WML) for wireless clients, and Excel for application clients. The Net.Data macro processor communicates with the HTTP Server through its CGI-BIN interface. Like other CGI-BIN programs, Net.Data is typically stored in the server’s CGI-BIN directory. Net.Data is accessed when a URL received by the server refers to the Net.Data macro processor executable, DB2WWW, in the CGI-BIN directory.

When a URL is received by the server that refers to the Net.Data macro processor program, the server starts an instance of the macro processor. It then passes essential information, including the name of the requested macro and the section of the macro to use. The macro processor then: * Reads and parses through the macro.

* Interprets all the macro statements.
* Dynamically builds the page.
* Sends the data to the HTTP server by writing to stdout. The macro writer has complete control over what format the generated data is in (for example: HTML or XML). The macro processor imposes no restrictions. After the text is passed back to the server, the macro processor ends. The resulting text is passed to the client (or browser) where the user interacts with it. Further requests from this user or any other user will result in the whole process just described taking place again.

%define DTW_PRINT_HEADER = “NO”

%html(cookie1) {
Content-type: text/html
Set-Cookie: UsrId=56, expires=Friday, 12-Dec-99, 12:00:00 GMT; path=/

Any text…
%}

%define DTW_PRINT_HEADER = “NO”

%html(cookie1) {
Content-type: text/html
Set-Cookie: UsrId=56, expires=Friday, 12-Dec-99, 12:00:00 GMT; path=/

Any text…
%}

Example :
To set a cookie in a Web macro, you need to tell Net.Data not to print out the Content-type header. This is done by setting the DTW_PRINT_HEADER variable to “NO”. Then, in the %HTML block that gets control, the first three lines must be the Content-type header, the Set-Cookie statement, and a blank line. The following example sets a cookie. 3.1.2 Hypertext Preprocessor (PHP)

PHP is an open-source server-side scripting language. A dynamic Web page interacts with the user, so that each user visiting the page sees customized information. PHP can also be used to create dynamic web pages that are generated from information accessed from a MySQL database. Attacker can embed PHP commands within a standard HTML page. PHP’s syntax is similar to that of C and Perl, making it easy to learn for anyone with basic programming skills. Another feature that PHP offers is connectivity to most of the common databases. PHP also offers integration with various external libraries, which allow the developer to do anything from generating PDF documents to parsing XML.

By default, when PHP creates a session file it stores it in /tmp. In the Webserve environment, however, attacker will create a session directory in the login directory of your account and write the session information there. For example, attacker may wish to create a directory named “sessions” (/ip/account/sessions) and write the session information there. To write session files to that directory you would use the following code in each file that uses sessions. Attacker does not store session information in the www or wwws directories. Attacker will need to do occasional cleanup of any unused session files in your account that aren’t deleted. Doing it this way will guarantee session persistence and will prevent potential server issues as a result of filling up /tmp. The specifics of how writing session files to /tmp can impact session persistence in the Webserve environment is provided below.

As indicated above, when PHP creates a session file, the default behavior is to store it in /tmp. The /tmp directory is local and independent to each of the backend web servers. Hence, if a request is made to server_1, it stores the session file in its own /tmp. If a subsequent request for the same user ends up going to server_2, it won’t find the original session file. The load balancers control how web requests are distributed across the backend web servers. These load balancers are configured to provide session persistence by tracking the IP address of the web browser and the backend web server to which a request is sent. The goal is to send all subsequent requests from a given web browser back to the same backend web server. As a result, normally the PHP session files in /tmp work as expected because the multiple requests for the same user is consistently sent to the same backend web server.

However, the load balancers can only cache so much data and eventually older data is overwritten by new incoming requests. This can cause the loss of persistence information. Since PHP allows you to specify the location of the session files (i.e., other than /tmp) you should be sure to create a session directory in the login of your account and write session information there. Doing this will require you to periodically do cleanup of unused session files that are not deleted. public function loginUser($username, $password) {

if(isset($_POST[‘login’])) {
if($username != ” && $password != ”) {
$sql = “SELECT * FROM `users` WHERE `username` = ‘”.$username.”‘ AND `password` = ‘”.$password.”‘”; $q = mysql_query($sql);
$row = mysql_fetch_array($q);
if(mysql_num_rows($q) > 0) {
if($row[‘level’] == ‘admin’) {
$_SESSION[‘user_level’] = ‘admin’;
}
else {
$_SESSION[‘user_level’] = ‘normal’;
}
$_SESSION[‘logged_in’] = 1;
header(‘location: account.php’);
}
else {
header(‘location: error2.php’);
// Return to page and show error
}
}
else {
header(‘location: error1.php’);
// Show error, when people have empty fields entered }
}
public function loginUser($username, $password) {
if(isset($_POST[‘login’])) {
if($username != ” && $password != ”) {
$sql = “SELECT * FROM `users` WHERE `username` = ‘”.$username.”‘ AND `password` = ‘”.$password.”‘”; $q = mysql_query($sql);
$row = mysql_fetch_array($q);
if(mysql_num_rows($q) > 0) {
if($row[‘level’] == ‘admin’) {
$_SESSION[‘user_level’] = ‘admin’;
}
else {
$_SESSION[‘user_level’] = ‘normal’;
}
$_SESSION[‘logged_in’] = 1;
header(‘location: account.php’);
}
else {
header(‘location: error2.php’);
// Return to page and show error
}
}
else {
header(‘location: error1.php’);
// Show error, when people have empty fields entered }
}
Example:

Security Issues

4.1An Ideal View
We use an online-banking example to explain what is involved in secure server-side scripting, and how proper abstractions can help. This application provides two services: showing the account balance (the “balance” service) and setting up a payment (the “payment” service). A user must be logged in to access the services. Although serving multiple users, this web application logically deals with one client at a time. In an ideal view, there are multiple orthogonal instances of the server program running, each taking care of a single client. Every single instance of the program can be viewed as a sequential program of a conventional application.

4.2A Limited Mechanism
The above ideal view cannot be directly implemented, because of some limitations of the underlying HTTP mechanism for web interactions. In particular, there is no persistent channel for a server program to obtain input from a client. Instead, HTTP supports a one-shot request-response model where a client requests resource identified by a URL, and a server responds with the resource if the request is accepted. Using HTTP, web interactions are typically carried out as a sequence of requests (form submissions providing user input) and responses (web pages presenting information): HTTP0→HTML0→HTTP1→HTML1→HTTP2→HTML2…

Using this model, a server program is often split into multiple fragments, each taking an HTTP request and producing an HTML response. In the response, there can be a web form with an embedded URL pointing to the next fragment, so that the next request is targeted correctly. Therefore, the workflow of our banking application is more accurately described as in Figure 2. There are 4 program fragments connected with URL embedding’s, as indicate by the dashed lines. In particular, because the payment service re- quires user input, the structure of the service loop in the ideal view can no longer be coded as an explicit loop. Instead, a goto style structure is exhibited through URL embedding’s. Such fragmentation and low-level control structures obscure the control flow. Besides obscurity, there is a bigger issue: since HTTP is state- less, server programs must maintain program states on their own. In the example, the user name obtained from the login input must be saved and restored explicitly across the later web interactions. In addition, one must somehow correlate incoming requests with specific clients, since multiple clients may be interacting with the server at the same time, although in logically separate transactions.

In general, a web application needs to encode states at a level above HTTP. Typically, a virtual concept of “a session” is used to refer to a logical transaction. Every session is associated with a unique ID, called SID. Saved program states and incoming client requests are both identified by the SID. As a result, much code in server programs is dedicated to managing sessions. Before generating a response, a server program must save state and embed the SID in the response. Upon receiving a request, the server program must obtain an SID from the request and load state. Based on the application, some parts of the state should be saved on the server, whereas others should be on the client via the cookie or URL embedding. These routine manipulations increase program complexity, reduce productivity, and extend the chances of programming errors.

4.3A Dangerous World
Assuming a programmer has taken care of the above issues correctly, the result program may still not be ready for deployment. The problem is security: clients in the real world may be malicious, or attackers may trick innocent clients into making mistakes. In- deed, there have been many common vulnerabilities identified. Se- cure programming solutions exist, but a programmer must be aware of all the issues involved and implement the related defenses. Most of the defenses are orthogonal to the business logic of specific web applications. Their handling further complicates server-side scripting language. We now briefly overview some representative security issues.

Cross-Site Request Forgery CSRF: An attacker may forge a request as if a user intended it; this is applicable when SIDs is stored in cookies. Given a vulnerable banking program, CSRF can be launched if a user, while logged in, opens a malicious email containing a crafted image link. Trying to load the image, the user’s browser may follow the link and send a request asking for a payment to be set up to the attacker. XSS: An attacker may inject code into the web page that a server program sends to a user. For example, an attacker sends to a user a crafted link with JavaScript code embedded; when the user loads the link, a vulnerable server program may propagate the code into the HTML response. The code, now coming from the server, gains the privilege of the server domain. It may then read the cookie set by the server and send it to the attacker. There are also second-order attacks that do not require the use of forged requests.

Session fixation: An attacker may trick a user into interacting with the server using a fixed SID. This is applicable if SIDs are embedded in URLs. A user may follow a link in an email, which claims to be from our banking site. The link takes the user to our site, but using an SID fixed by an attacker. If the server programs use the same SID for later interactions after the user logs in, the knowledge of the SID will grant the attacker the user’s privileges. Others: Many other aspects affect security. Since a web application is implemented as multiple program fragments, each fragment is open as a service interface. An attacker could make up requests to the interfaces without following the links in server responses. Using crafted requests, they could poison program states (e.g., by modifying naïve implementations of client-side states), inject malformed input (e.g., by exploiting insufficient input validation), or circumvent workflows (e.g., by using the “back” button). Programmers need to be aware of all these issues and follow the relevant security practices. In the result code, business logic is intertwined with security manipulations. Consequently, secure web programming is difficult, and web programs are hard to maintain.

Conclusion
Web applications reflect a different computation model than conventional software, and the security issues therein deserve careful study from both language principles and practical implementations. This paper serves as a useful step towards building a formal foundation for secure server-side scripting language. In particular, we propose two self-contained formalizations on the topic, using familiar language concepts such as continuations, threads, and small-step semantics.

References

[1] Case Study: Python in a Commercial Environment, by Greg Stein, Microsoft, in Proceedings of the 6th International Python Conference, http://www.python.org/workshops/1997-10/proceedings/

[2] Alice Virtual Reality project at Carnegie Mellon University, http://alice.cs.cmu.edu

[3] Robert Martin. Are scripting languages the wave of the future? http://www.itworld.com/AppDev/1262/itw-0314- rcmappdevint/

[4] Ruslan Bogatyrov. The nature and evolution of scripting languages. http://www.osp.ru/pcworld/2001/11/144.htm

[5] C.Brabrand,A.Møller,andM.I.Schwartzbach.The<bigwig> project. ACM Trans. on Internet Technology, 2(2):79–114, 2002.
[6] A. S. Christensen, A. Møller, and M. I. Schwartzbach. Extending 
Java for high-level Web service construction. ACM Trans. on 
Programming Languages and Systems, 25(6):814–875, Nov. 2003.
[7] S.ChristeyandR.A.Martin.Vulnerabilitytypedistributionsin 
CVE.
http://cve.mitre.org/docs/vuln-trends, 2007.
[8] S.Ducasse,A.Lienhard,andL.Renggli.Seaside—amultiple 
control flow web application framework. In Proc. 12th International 
Smalltalk Conference, pages 231–257, Sept. 2004.
[9] Ú. Erlingsson, B. Livshits, and Y. Xie. End-to-end web application 
security. In Proc. 11th Workshop on Hot Topics in Operating 
Systems, May 2007.
[10] P.Graunke,R.B.Findler,S.Krishnamurthi,andM.Felleisen. 
Automatically restructuring programs for the Web. In Proc. 16th International Conference on Automated Software Engineering, pages 211–222, Nov. 2001.