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.