<HTML ><HEAD ><TITLE >Prevent Cross-site Malicious Content on Input</TITLE ><META NAME="GENERATOR" CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK REL="HOME" TITLE="Secure Programming for Linux and Unix HOWTO" HREF="index.html"><LINK REL="UP" TITLE="Validate All Input" HREF="input.html"><LINK REL="PREVIOUS" TITLE="Character Encoding" HREF="character-encoding.html"><LINK REL="NEXT" TITLE="Filter HTML/URIs That May Be Re-presented" HREF="filter-html.html"></HEAD ><BODY CLASS="SECT1" BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#840084" ALINK="#0000FF" ><DIV CLASS="NAVHEADER" ><TABLE SUMMARY="Header navigation table" WIDTH="100%" BORDER="0" CELLPADDING="0" CELLSPACING="0" ><TR ><TH COLSPAN="3" ALIGN="center" >Secure Programming for Linux and Unix HOWTO</TH ></TR ><TR ><TD WIDTH="10%" ALIGN="left" VALIGN="bottom" ><A HREF="character-encoding.html" ACCESSKEY="P" >Prev</A ></TD ><TD WIDTH="80%" ALIGN="center" VALIGN="bottom" >Chapter 5. Validate All Input</TD ><TD WIDTH="10%" ALIGN="right" VALIGN="bottom" ><A HREF="filter-html.html" ACCESSKEY="N" >Next</A ></TD ></TR ></TABLE ><HR ALIGN="LEFT" WIDTH="100%"></DIV ><DIV CLASS="SECT1" ><H1 CLASS="SECT1" ><A NAME="INPUT-PROTECTION-CROSS-SITE" ></A >5.10. Prevent Cross-site Malicious Content on Input</H1 ><P >Some programs accept data from one untrusted user and pass that data on to a second user; the second user's application may then process that data in a way harmful to the second user. This is a particularly common problem for web applications, we'll call this problem ``cross-site malicious content.'' In short, you cannot accept input (including any form data) without checking, filtering, or encoding it. For more information, see <A HREF="cross-site-malicious-content.html" >Section 7.15</A >.</P ><P >Fundamentally, this means that all web application input must be filtered (so characters that can cause this problem are removed), encoded (so the characters that can cause this problem are encoded in a way to prevent the problem), or validated (to ensure that only ``safe'' data gets through). Filtering and validation should often be done at the input, but encoding can be done either at input or output time. If you're just passing the data through without analysis, it's probably better to encode the data on input (so it won't be forgotten), but if you're processing the data, there are arguments for encoding on output instead.</P ></DIV ><DIV CLASS="NAVFOOTER" ><HR ALIGN="LEFT" WIDTH="100%"><TABLE SUMMARY="Footer navigation table" WIDTH="100%" BORDER="0" CELLPADDING="0" CELLSPACING="0" ><TR ><TD WIDTH="33%" ALIGN="left" VALIGN="top" ><A HREF="character-encoding.html" ACCESSKEY="P" >Prev</A ></TD ><TD WIDTH="34%" ALIGN="center" VALIGN="top" ><A HREF="index.html" ACCESSKEY="H" >Home</A ></TD ><TD WIDTH="33%" ALIGN="right" VALIGN="top" ><A HREF="filter-html.html" ACCESSKEY="N" >Next</A ></TD ></TR ><TR ><TD WIDTH="33%" ALIGN="left" VALIGN="top" >Character Encoding</TD ><TD WIDTH="34%" ALIGN="center" VALIGN="top" ><A HREF="input.html" ACCESSKEY="U" >Up</A ></TD ><TD WIDTH="33%" ALIGN="right" VALIGN="top" >Filter HTML/URIs That May Be Re-presented</TD ></TR ></TABLE ></DIV ></BODY ></HTML >