# 
# AUTHOR <EMAIL@ADDRESS>, YEAR.
#
msgid ""
msgstr ""
"Project-Id-Version: 0\n"
"POT-Creation-Date: 2013-03-12T03:19:45\n"
"PO-Revision-Date: 2013-03-12T03:19:45\n"
"Last-Translator: Automatically generated\n"
"Language-Team: None\n"
"MIME-Version: 1.0\n"
"Content-Type: application/x-publican; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Tag: title
#, no-c-format
msgid "Serialization and Deserialization"
msgstr ""

#. Tag: para
#, no-c-format
msgid "Protocol decoders and file format parsers are often the most-exposed part of an application because they are exposed with little or no user interaction and before any authentication and security checks are made. They are also difficult to write robustly in languages which are not memory-safe."
msgstr ""

#. Tag: title
#, no-c-format
msgid "Recommendations for manually written decoders"
msgstr ""

#. Tag: para
#, no-c-format
msgid "For C and C++, the advice in <xref linkend=\"sect-Defensive_Coding-C-Pointers\" /> applies. In addition, avoid non-character pointers directly into input buffers. Pointer misalignment causes crashes on some architectures."
msgstr ""

#. Tag: para
#, no-c-format
msgid "When reading variable-sized objects, do not allocate large amounts of data solely based on the value of a size field. If possible, grow the data structure as more data is read from the source, and stop when no data is available. This helps to avoid denial-of-service attacks where little amounts of input data results in enormous memory allocations during decoding. Alternatively, you can impose reasonable bounds on memory allocations, but some protocols do not permit this."
msgstr ""

#. Tag: title
#, no-c-format
msgid "Protocol design"
msgstr ""

#. Tag: para
#, no-c-format
msgid "Binary formats with explicit length fields are more difficult to parse robustly than those where the length of dynamically-sized elements is derived from sentinel values. A protocol which does not use length fields and can be written in printable ASCII characters simplifies testing and debugging. However, binary protocols with length fields may be more efficient to parse."
msgstr ""

#. Tag: title
#, no-c-format
msgid "Library support for deserialization"
msgstr ""

#. Tag: para
#, no-c-format
msgid "For some languages, generic libraries are available which allow to serialize and deserialize user-defined objects. The deserialization part comes in one of two flavors, depending on the library. The first kind uses type information in the data stream to control which objects are instantiated. The second kind uses type definitions supplied by the programmer. The first one allows arbitrary object instantiation, the second one generally does not."
msgstr ""

#. Tag: para
#, no-c-format
msgid "The following serialization frameworks are in the first category, are known to be unsafe, and must not be used for untrusted data:"
msgstr ""

#. Tag: para
#, no-c-format
msgid "Python's <package>pickle</package> and <package>cPickle</package> modules"
msgstr ""

#. Tag: para
#, no-c-format
msgid "Perl's <package>Storable</package> package"
msgstr ""

#. Tag: para
#, no-c-format
msgid "Java serialization (<type>java.io.ObjectInputStream</type>)"
msgstr ""

#. Tag: para
#, no-c-format
msgid "PHP serialization (<function>unserialize</function>)"
msgstr ""

#. Tag: para
#, no-c-format
msgid "Most implementations of YAML"
msgstr ""

#. Tag: para
#, no-c-format
msgid "When using a type-directed deserialization format where the types of the deserialized objects are specified by the programmer, make sure that the objects which can be instantiated cannot perform any destructive actions in their destructors, even when the data members have been manipulated."
msgstr ""

#. Tag: para
#, no-c-format
msgid "JSON decoders do not suffer from this problem. But you must not use the <function>eval</function> function to parse JSON objects in Javascript; even with the regular expression filter from RFC 4627, there are still information leaks remaining."
msgstr ""

#. Tag: title
#, no-c-format
msgid "XML serialization"
msgstr ""

#. Tag: title
#, no-c-format
msgid "External references"
msgstr ""

#. Tag: para
#, no-c-format
msgid "XML documents can contain external references. They can occur in various places."
msgstr ""

#. Tag: para
#, no-c-format
msgid "In the DTD declaration in the header of an XML document:"
msgstr ""

#. Tag: programlisting
#, no-c-format
msgid "\n"
"&lt;!DOCTYPE html PUBLIC\n"
"  \"-//W3C//DTD XHTML 1.0 Transitional//EN\"\n"
"  \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\"&gt;\n"
"	    "
msgstr ""

#. Tag: para
#, no-c-format
msgid "In a namespace declaration:"
msgstr ""

#. Tag: programlisting
#, no-c-format
msgid "\n"
"&lt;xsd:schema xmlns:xsd=\"http://www.w3.org/2001/XMLSchema\"&gt;\n"
"	    "
msgstr ""

#. Tag: para
#, no-c-format
msgid "In an entity defintion:"
msgstr ""

#. Tag: programlisting
#, no-c-format
msgid "\n"
"&lt;!ENTITY sys SYSTEM \"http://www.example.com/ent.xml\"&gt;\n"
"&lt;!ENTITY pub PUBLIC \"-//Example//Public Entity//EN\"\n"
"  \"http://www.example.com/pub-ent.xml\"&gt;\n"
"	    "
msgstr ""

#. Tag: para
#, no-c-format
msgid "In a notation:"
msgstr ""

#. Tag: programlisting
#, no-c-format
msgid "\n"
"&lt;!NOTATION not SYSTEM \"../not.xml\"&gt;\n"
"	    "
msgstr ""

#. Tag: para
#, no-c-format
msgid "Originally, these external references were intended as unique identifiers, but by many XML implementations, they are used for locating the data for the referenced element. This causes unwanted network traffic, and may disclose file system contents or otherwise unreachable network resources, so this functionality should be disabled."
msgstr ""

#. Tag: para
#, no-c-format
msgid "Depending on the XML library, external referenced might be processed not just when parsing XML, but also when generating it."
msgstr ""

#. Tag: title
#, no-c-format
msgid "Entity expansion"
msgstr ""

#. Tag: para
#, no-c-format
msgid "When external DTD processing is disabled, an internal DTD subset can still contain entity definitions. Entity declarations can reference other entities. Some XML libraries expand entities automatically, and this processing cannot be switched off in some places (such as attribute values or content models). Without limits on the entity nesting level, this expansion results in data which can grow exponentially in length with size of the input. (If there is a limit on the nesting level, the growth is still polynomial, unless further limits are imposed.)"
msgstr ""

#. Tag: para
#, no-c-format
msgid "Consequently, the processing internal DTD subsets should be disabled if possible, and only trusted DTDs should be processed. If a particular XML application does not permit such restrictions, then application-specific limits are called for."
msgstr ""

#. Tag: title
#, no-c-format
msgid "XInclude processing"
msgstr ""

#. Tag: para
#, no-c-format
msgid "XInclude processing can reference file and network resources and include them into the document, much like external entity references. When parsing untrusted XML documents, XInclude processing should be truned off."
msgstr ""

#. Tag: para
#, no-c-format
msgid "XInclude processing is also fairly complex and may pull in support for the XPointer and XPath specifications, considerably increasing the amount of code required for XML processing."
msgstr ""

#. Tag: title
#, no-c-format
msgid "Algorithmic complexity of XML validation"
msgstr ""

#. Tag: para
#, no-c-format
msgid "DTD-based XML validation uses regular expressions for content models. The XML specification requires that content models are deterministic, which means that efficient validation is possible. However, some implementations do not enforce determinism, and require exponential (or just polynomial) amount of space or time for validating some DTD/document combinations."
msgstr ""

#. Tag: para
#, no-c-format
msgid "XML schemas and RELAX NG (via the <literal>xsd:</literal> prefix) directly support textual regular expressions which are not required to be deterministic."
msgstr ""

#. Tag: title
#, no-c-format
msgid "Using Expat for XML parsing"
msgstr ""

#. Tag: para
#, no-c-format
msgid "By default, Expat does not try to resolve external IDs, so no steps are required to block them. However, internal entity declarations are processed. Installing a callback which stops parsing as soon as such entities are encountered disables them, see <xref linkend=\"ex-Defensive_Coding-Tasks-Serialization-XML-Expat-EntityDeclHandler\" />. Expat does not perform any validation, so there are no problems related to that."
msgstr ""

#. Tag: title
#, no-c-format
msgid "Disabling XML entity processing with Expat"
msgstr ""

#. Tag: para
#, no-c-format
msgid "This handler must be installed when the <literal>XML_Parser</literal> object is created (<xref linkend=\"ex-Defensive_Coding-Tasks-Serialization-XML-Expat-Create\" />)."
msgstr ""

#. Tag: title
#, no-c-format
msgid "Creating an Expat XML parser"
msgstr ""

#. Tag: para
#, no-c-format
msgid "It is also possible to reject internal DTD subsets altogeher, using a suitable <literal>XML_StartDoctypeDeclHandler</literal> handler installed with <function>XML_SetDoctypeDeclHandler</function>."
msgstr ""

#. Tag: title
#, no-c-format
msgid "Using OpenJDK for XML parsing and validation"
msgstr ""

#. Tag: para
#, no-c-format
msgid "OpenJDK contains facilities for DOM-based, SAX-based, and StAX-based document parsing. Documents can be validated against DTDs or XML schemas."
msgstr ""

#. Tag: para
#, no-c-format
msgid "The approach taken to deal with entity expansion differs from the general recommendation in <xref linkend=\"sect-Defensive_Coding-Tasks-Serialization-XML-Entities\" />. We enable the the feature flag <literal>javax.xml.XMLConstants.FEATURE_SECURE_PROCESSING</literal>, which enforces heuristic restrictions on the number of entity expansions. Note that this flag alone does not prevent resolution of external references (system IDs or public IDs), so it is slightly misnamed."
msgstr ""

#. Tag: para
#, no-c-format
msgid "In the following sections, we use helper classes to prevent external ID resolution."
msgstr ""

#. Tag: title
#, no-c-format
msgid "Helper class to prevent DTD external entity resolution in OpenJDK"
msgstr ""

#. Tag: title
#, no-c-format
msgid "Helper class to prevent schema resolution in OpenJDK"
msgstr ""

#. Tag: para
#, no-c-format
msgid "<xref linkend=\"ex-Defensive_Coding-Tasks-Serialization-XML-OpenJDK-Imports\" /> shows the imports used by the examples."
msgstr ""

#. Tag: title
#, no-c-format
msgid "Java imports for OpenJDK XML parsing"
msgstr ""

#. Tag: title
#, no-c-format
msgid "DOM-based XML parsing and DTD validation in OpenJDK"
msgstr ""

#. Tag: para
#, no-c-format
msgid "This approach produces a <literal>org.w3c.dom.Document</literal> object from an input stream. <xref linkend=\"ex-Defensive_Coding-Tasks-Serialization-XML-OpenJDK_Parse-DOM\" /> use the data from the <literal>java.io.InputStream</literal> instance in the <literal>inputStream</literal> variable."
msgstr ""

#. Tag: title
#, no-c-format
msgid "DOM-based XML parsing in OpenJDK"
msgstr ""

#. Tag: para
#, no-c-format
msgid "External entity references are prohibited using the <literal>NoEntityResolver</literal> class in <xref linkend=\"ex-Defensive_Coding-Tasks-Serialization-XML-OpenJDK-NoEntityResolver\" />. Because external DTD references are prohibited, DTD validation (if enabled) will only happen against the internal DTD subset embedded in the XML document."
msgstr ""

#. Tag: para
#, no-c-format
msgid "To validate the document against an external DTD, use a <literal>javax.xml.transform.Transformer</literal> class to add the DTD reference to the document, and an entity resolver which whitelists this external reference."
msgstr ""

#. Tag: title
#, no-c-format
msgid "XML Schema validation in OpenJDK"
msgstr ""

#. Tag: para
#, no-c-format
msgid "<xref linkend=\"ex-Defensive_Coding-Tasks-Serialization-XML-OpenJDK_Parse-XMLSchema_SAX\" /> shows how to validate a document against an XML Schema, using a SAX-based approach. The XML data is read from an <literal>java.io.InputStream</literal> in the <literal>inputStream</literal> variable."
msgstr ""

#. Tag: title
#, no-c-format
msgid "SAX-based validation against an XML schema in OpenJDK"
msgstr ""

#. Tag: para
#, no-c-format
msgid "The <literal>NoResourceResolver</literal> class is defined in <xref linkend=\"ex-Defensive_Coding-Tasks-Serialization-XML-OpenJDK-NoResourceResolver\" />."
msgstr ""

#. Tag: para
#, no-c-format
msgid "If you need to validate a document against an XML schema, use the code in <xref linkend=\"ex-Defensive_Coding-Tasks-Serialization-XML-OpenJDK_Parse-DOM\" /> to create the document, but do not enable validation at this point. Then use <xref linkend=\"ex-Defensive_Coding-Tasks-Serialization-XML-OpenJDK_Parse-XMLSchema_DOM\" /> to perform the schema-based validation on the <literal>org.w3c.dom.Document</literal> instance <literal>document</literal>."
msgstr ""

#. Tag: title
#, no-c-format
msgid "Validation of a DOM document against an XML schema in OpenJDK"
msgstr ""

#. Tag: title
#, no-c-format
msgid "Protocol Encoders"
msgstr ""

#. Tag: para
#, no-c-format
msgid "For protocol encoders, you should write bytes to a buffer which grows as needed, using an exponential sizing policy. Explicit lengths can be patched in later, once they are known. Allocating the required number of bytes upfront typically requires separate code to compute the final size, which must be kept in sync with the actual encoding step, or vulnerabilities may result. In multi-threaded code, parts of the object being deserialized might change, so that the computed size is out of date."
msgstr ""

#. Tag: para
#, no-c-format
msgid "You should avoid copying data directly from a received packet during encoding, disregarding the format. Propagating malformed data could enable attacks on other recipients of that data."
msgstr ""

#. Tag: para
#, no-c-format
msgid "When using C or C++ and copying whole data structures directly into the output, make sure that you do not leak information in padding bytes between fields or at the end of the <literal>struct</literal>."
msgstr ""

