{% extends 'introduction/base.html' %}
{% block content %}
{% block title %}
<title>Software and Data Integrity Failures</title>
{% endblock %}
<div class="content">
	<h3>Software and Data Integrity Failures</h3>
	<div class="box">
		<h4>What is Software and Data Integrity Failures</h4>
		<p class="bp">
			Exploitation of deserialization is somewhat difficult, as off the shelf exploits rarely work without changes or
			tweaks to the underlying exploit code.
			Software and data integrity failures relate to code and infrastructure that does not protect against integrity
             violations. An example of this is where an application relies upon plugins, libraries, or modules from
              untrusted sources, repositories, and content delivery networks (CDNs). An insecure CI/CD pipeline can
               introduce the potential for unauthorized access, malicious code, or system compromise. Lastly, many
                applications now include auto-update functionality, where updates are downloaded without sufficient
                 integrity verification and applied to the previously trusted application. Attackers could potentially
                  upload their own updates to be distributed and run on all installations. Another example is where objects 
                   or data are encoded or serialized into a structure that an attacker can see and modify is vulnerable to
                    insecure deserialization.
		</p>

		<button class="coll btn btn-info">Lab 1 Details</button>
		<div class="lab">
			<p class="bp">
				This Lab consists of a Page that has some content only available to for the admin to see, How can we access that
				page as admin? How is our role defined?
			</p>
			<p class="bp">If we check the cookie we see that it is base64 encoded, on decoding we realise it is pickle
				serialised and we can see some attributes, can you change the attributes to make the page readable?
			</p>
			<p class="bp">Hint: try to flip the bit of the admin from ...admin\x94K\x00... to ...admin\x94K\x00...
			</p>
			<br>
			<div align="right">
				<button class="btn btn-info" type="button" onclick="window.location.href='/insec_des_lab'">Access Lab</button>
			</div>
		</div>
        <button class="coll btn btn-info">Lab 2 Details</button>
		<div class="lab">
			<p class="bp">
				This Lab contains a executable file to download, you can access the lab from the Access Lab button or from the below link 
                Download the file and figure out whats going on. 
			</p>
			<a href='/2021/A8/lab2?username=user+<script>document.getElementById%28"download_link"%29.setAttribute%28"href"%2C"%2Fstatic%2Ffake.txt"%29%3B<%2Fscript>user+<script>document.getElementById%28"download_link"%29.setAttribute%28"href"%2C"%2Fstatic%2Ffake.txt"%29%3B<%2Fscript>'>Download File</a>
			
			<div align="right">
				<button class="btn btn-info" type="button" onclick="window.location.href='/2021/A8/lab2'">Access Lab</button>
			</div>
		</div>
		<h4>Insecure Deserialization</h4>
		<p class="bp">
			Applications and APIs will be vulnerable if they deserialize hostile or tampered objects supplied by an attacker.
			This can result in two primary types of attacks:
		</p>
		<ul>
			<li>Object and data structure related attacks where the attacker modifies application logic or achieves arbitrary
				remote code execution if there are classes available to the application that can change behavior during or after
				deserialization.</li>
			<li>Typical data tampering attacks such as access-control-related attacks where existing data structures are used
				but the content is changed.</li>
		</ul>
		<h4>
			Serialization may be used in applications for:
		</h4>
		<ul>
			<li>Remote- and inter-process communication (RPC/IPC)</li>
			<li>Wire protocols, web services, message brokers</li>
			<li>Caching/Persistence</li>
			<li>Databases, cache servers, file systems</li>
			<li>HTTP cookies, HTML form parameters, API authentication tokens</li>
		</ul>
		<h4>
			How to Prevent
		</h4>
		<p class="bp">The only safe architectural pattern is not to accept serialized objects from untrusted sources or to
			use serialization mediums that only permit primitive data types. If that is not possible, consider one of more of
			the following:
		</p>
		<ul>
			<li>Implementing integrity checks such as digital signatures on any serialized objects to prevent hostile object
				creation or data tampering.</li>
			<li>Enforcing strict type constraints during deserialization before object creation as the code typically expects
				a definable set of classes. Bypasses to this technique have been demonstrated, so reliance solely on this is not
				advisable.</li>
			<li>Isolating and running code that deserializes in low privilege environments when possible.</li>
			<li>Log deserialization exceptions and failures, such as where the incoming type is not the expected type, or the
				deserialization throws exceptions.</li>
			<li>Restricting or monitoring incoming and outgoing network connectivity from containers or servers that
				deserialize.
				Monitoring deserialization, alerting if a user deserializes constantly.</li>
		</ul>
	</div>
</div>
{% endblock %}