Saturday, May 26, 2018

Why use Apache Server Side Includes (SSI) for Web scripting

  • Simple
  • Fast
  • Flexible
  • Secure (if configured properly)
  • Low server load
Apache SSI (also called XSSI, extended server side includes) has several advantages over other server-side technologies:
Easy to learn
A small learning curve makes XSSI accessible to people with limited programming experience. XSSI is programmer-efficient because it requires very  little debugging.
Mature
Well-tested code and a stable API make future surprises unlikely.
Lightweight
XSSI can deliver popular features such as printer-friendly versions, article partitioning, and hierarchical menus without client-side scripting or a database back end. Maintenance becomes easier--and cheaper.
Efficient
Contrary to early-day warnings that XSSI would bog down a web server, XSSI is probably the most resource-efficient of all dynamic technologies. For example, according to the Apache Hello World Benchmarks (see XSSI Resources), mod_include, the base module implementing XSSI in Apache, can serve more Hello World pages per second than other dynamic content-generation technologies.
Secure
In particular, if you do not include the output of arbitrary web server executable programs. Also, content maintenance is at the file system level. Desktop html editors make that an advantage because Web-based CMS write  to the file system. That's the vector for CMS attacks. See below for a security discussion.
Ubiquitous
Present in virtually every Apache installations, because its implementation is a base module.
Complementary
Combined with web site templates, XSSI can decrease maintenance time and increase sitewide consistency. 
It is easy to integrate with client-side technologies, including cascaded style sheets, JavaScript, and other dynamic objects such as Flash and Java applets.
On the server side, it's integrated with Apache CGI (Apache's original way of programming Web pages). Thus it can be combined with any other programming language that supports stdin/stdout. CGI is language neutral. 
Desktop GUI html editors can include it by switching to html mode. Can even use an online editor like blogger.com and copy-paste the html.
Forward-looking
It can integrate with any text-based document, including XML and RSS.
Powerful
CGI has access to all programming languages, commands and scripts on the system including server side Javascript. It can get data, code, etc. from other servers. It can make database calls. There's practically no limit to what a programmer can do using CGI integrated with SSI.

Apache's eXtended Server Side Includes Onlamp.com, by Kostas Pentikousis 07/07/2005

 

But, is it secure? Various authors have challenged Apache SSI security. For example:

Protecting Web Servers from Security Holes in Server-Side Includes by Jared Karro, Jie Wang, Division of Computer Science, University of North Carolina at Greensboro, Greensboro, NC 27402, USA, Jared Karro@uncg.edu, wang@uncg.edu
All of the examples this paper sites are internal attacks. Controlling who can edit the Web site and what user Apache runs as completely negate the claimed problems.

Generally, when people talk about the security of a Web scripting language, they are referring to external attacks. No one will claim that a Web language is totally immune, but SSI has, historically, had the fewest issues of any Web programming language.

Other claimed vulnerabilities:
  • Server-Side Includes (SSI) Injection
    • The authors provide no explanation of how the injection is to be accomplished. Setting the file system permissions so the Web server can't write to it and turning off Exec permission, which are standard procedures for securing an Apache site, should eliminate any possibility of this working.
    • Perhaps they are referring to using the query string as a variable in an SSI command. Programmers must be cautioned to never do this without checking the content of the query string.
So, what's wrong with it?
  • Limited function in of itself compared to other Web languages, e.g. PHP. Using CGI, it can do anything the others can, but programmers may find breaking the work into two environments inconvenient.
  • Requires understanding of stdin/stdout to use CGI.
  • Programmers must pay attention to the data coming in to ensure it doesn't contain executable code. Best practice is to never execute any part of the parameters or form input. Some CGI libraries, e.g. in CPAN and MIT's cgic take care of this housekeeping.
  • The biggest problem is lack of exposure. Most Web programmers don't know it exists.

Tuesday, May 22, 2018

Turning Apache SSI usage on its head.

Most people who talk about templating with Apache Server-side Includes scripting (SSI) have HTML pages pull in pieces of common code such as styles, headers, footers and so on, then hard code the content in the page. This technique certainly reduces the amount of code in each page. And, one can make some changes in a single place. In programming parlance, it modularizes the code. This approach has drawbacks, though.
  • Depending on what is pulled in, changing the structure of all the pages in the site may mean editing many files.
  • The content can't be presented in different ways for different purposes. It can't be reused.
So, what if we turn this concept on its head? What if the content calls the “page”, or more broadly the “template” rather than each page having content. What would that look like?

SSI can set variables. The variables can contain anything that is a string. The variables can be substituted for text just about anywhere, including in the URI in an SSI command.

What does that mean? It means that content can be put in a file that calls a “page” to display itself. The steps are:
  1. Set one or more variables with content.
  2. Call a template file, either a fixed one, or, and here's the beauty of it, one whose path is in a variable that was set before the content file was called.
  3. The template file puts the content variables in the appropriate places.
Why go to this trouble? Because the template file that’s called can be different depending on the desired output. One time it can be a complete HTML page. Another time it can be an HTML fragment such as a paragraph or a list element. Another time it can be an RSS feed item. Another time it can be Javascript variables. The same content. Only the template changes.

What's more, one template can be used for many pages, potentially an entire site. So, if the site structure or style changes, only one file has to be modified.

In some sense, this turns SSI into an object-oriented system, bringing it into the modern era of system architecture. The variables are object attributes and the template file is the method. What's more, the method can be anything. Unlike most OO languages, it doesn't have to be hard coded. (Although it could be by using #if conditional processing to choose among a fixed set of methods.)

Regardless, the possible uses of this technique are limited only by one’s imagination. The output can be anything that is deliverable in response to a Web request, even JSON. And, it can be driven by parameters in the URL that called it. (Apache SSI has access to the query string.) RESTful services anyone?