IA 321: Information and

Communication Systems Security

Instructor:
Dr. Jabhera Matogoro
Office# B13 – CIVE Administration Block
E-Mail: [email protected]
Phone: +255 784 423 615
Presented by Matogoro J 1
 Course Aim
• The course will discuss the importance of
information and Communication technology
to any modern organization
• It also emphasizes the importance of
developing secure information systems
• The course will cover diverse issues on
security management.

Presented by Matogoro J 2
 Course Objective
• The main objectives of this course is to
introduce to students the importance and
techniques for ensuring security to
information and communication
technology (ICT) systems.
• The programming language for this course
is JAVA.

Presented by Matogoro J 3
 Learning Outcomes
• Upon completion of this course, students should:
1. Explain the fundamental concepts, principles, and
mechanisms in ICT security
2. Analyze the basic cryptographic concepts commonly
used techniques and protocols
3. Classify of common ICT vulnerabilities and
techniques to address these vulnerabilities
4. Provide background for advanced topics in ICT
security and prepare students to work in information
system security.

Presented by Matogoro J 4
 Learning Outcomes
• Upon completion of this course, students should:
1. Explain the fundamental concepts, principles, and
mechanisms in ICT security
2. Analyze the basic cryptographic concepts commonly
used techniques and protocols
3. Classify of common ICT vulnerabilities and
techniques to address these vulnerabilities
4. Provide background for advanced topics in ICT
security and prepare students to work in information
system security.

Presented by Matogoro J 5
TOP TEN WEB APPLICATION
VULNERABILITIES

Presented by Matogoro J 6
 A01:2021-Broken Access Control
• Access control enforces policy such that users
cannot act outside of their intended
permissions.
• Failures typically lead to unauthorized
information disclosure, modification, or
destruction of all data or performing a
business function outside the user's limits.
Common access control vulnerabilities
include:
Presented by Matogoro J 7
 A01:2021-Broken Access Control
• Violation of the principle of least privilege or deny by default,
where access should only be granted for particular
capabilities, roles, or users, but is available to anyone.
• Bypassing access control checks by modifying the URL
(parameter tampering or force browsing), internal application
state, or the HTML page, or by using an attack tool modifying
API requests.
• Permitting viewing or editing someone else's account, by
providing its unique identifier (insecure direct object
references)
• Accessing API with missing access controls for POST, PUT and
DELETE.
Presented by Matogoro J 8
 A01:2021-Broken Access Control
• Elevation of privilege. Acting as a user without being logged in
or acting as an admin when logged in as a user.
• Metadata manipulation, such as replaying or tampering with a
JSON Web Token (JWT) access control token, or a cookie or
hidden field manipulated to elevate privileges or abusing JWT
invalidation.
• CORS misconfiguration allows API access from
unauthorized/untrusted origins.
• Force browsing to authenticated pages as an unauthenticated
user or to privileged pages as a standard user.

Presented by Matogoro J 9
 A02:2021-Cryptographic Failures
• The first thing is to determine the protection needs
of data in transit and at rest.
• For example, passwords, credit card numbers, health
records, personal information, and business secrets
require extra protection, mainly if that data falls
under privacy laws, e.g., EU's General Data
Protection Regulation (GDPR), or regulations, e.g.,
financial data protection such as PCI Data Security
Standard (PCI DSS).

Presented by Matogoro J 10
 A02:2021-Cryptographic Failures
• Is any data transmitted in clear text? This concerns protocols
such as HTTP, SMTP, FTP also using TLS upgrades like
STARTTLS. External internet traffic is hazardous. Verify all
internal traffic, e.g., between load balancers, web servers, or
back-end systems.
• Are any old or weak cryptographic algorithms or protocols
used either by default or in older code?
• Are default crypto keys in use, weak crypto keys generated or
re-used, or is proper key management or rotation missing?
Are crypto keys checked into source code repositories?
• Is encryption not enforced, e.g., are any HTTP headers
(browser) security directives or headers missing?
Presented by Matogoro J 11
 A02:2021-Cryptographic Failures
• Is the received server certificate and the trust chain properly
validated?
• Are initialization vectors ignored, reused, or not generated
sufficiently secure for the cryptographic mode of operation? Is
an insecure mode of operation such as ECB in use? Is
encryption used when authenticated encryption is more
appropriate?
• Are passwords being used as cryptographic keys in absence of
a password base key derivation function?

Presented by Matogoro J 12
 A02:2021-Cryptographic Failures
• Is randomness used for cryptographic purposes that was not
designed to meet cryptographic requirements? Even if the correct
function is chosen, does it need to be seeded by the developer, and
if not, has the developer over-written the strong seeding
functionality built into it with a seed that lacks sufficient
entropy/unpredictability?
• Are deprecated hash functions such as MD5 or SHA1 in use, or are
non-cryptographic hash functions used when cryptographic hash
functions are needed?
• Are deprecated cryptographic padding methods such as PKCS
number 1 v1.5 in use?
• Are cryptographic error messages or side channel information
exploitable, for example in the form of padding oracle attacks?
Presented by Matogoro J 13
 A03:2021-Injection
• An application is vulnerable to attack when:
– User-supplied data is not validated, filtered, or sanitized by
the application.
– Dynamic queries or non-parameterized calls without
context-aware escaping are used directly in the interpreter.
– Hostile data is used within object-relational mapping
(ORM) search parameters to extract additional, sensitive
records.
– Hostile data is directly used or concatenated. The SQL or
command contains the structure and malicious data in
dynamic queries, commands, or stored procedures.
Presented by Matogoro J 14
 A03:2021-Injection
• Some of the more common injections are SQL, NoSQL, OS
command, Object Relational Mapping (ORM), and Expression
Language (EL) or Object Graph Navigation Library (OGNL)
injection.
• Source code review is the best method of detecting if
applications are vulnerable to injections.
• Automated testing of all parameters, headers, URL, cookies,
JSON, SOAP, and XML data inputs is strongly encouraged.
• Organizations can include static (SAST), dynamic (DAST), and
interactive (IAST) application security testing tools into the
CI/CD pipeline to identify introduced injection flaws before
production deployment.
Presented by Matogoro J 15
 A04:2021-Insecure Design
• Insecure design is a broad category representing different
weaknesses, expressed as “missing or ineffective control
design.”
• Insecure design is not the source for all other Top 10 risk
categories.
• There is a difference between insecure design and insecure
implementation.
• We differentiate between design flaws and implementation
defects for a reason, they have different root causes and
remediation.

Presented by Matogoro J 16
 A04:2021-Insecure Design
• A secure design can still have implementation defects leading
to vulnerabilities that may be exploited.
• An insecure design cannot be fixed by a perfect
implementation as by definition, needed security controls
were never created to defend against specific attacks.
• One of the factors that contribute to insecure design is the
lack of business risk profiling inherent in the software or
system being developed, and thus the failure to determine
what level of security design is required.

Presented by Matogoro J 17
 A04:2021-Insecure Design
• Requirements and Resource Management
– Collect and negotiate the business requirements for an
application with the business, including the protection
requirements concerning confidentiality, integrity, availability,
and authenticity of all data assets and the expected business
logic.
– Take into account how exposed your application will be and if
you need segregation of tenants (additionally to access control).
– Compile the technical requirements, including functional and
non-functional security requirements.
– Plan and negotiate the budget covering all design, build, testing,
and operation, including security activities.

Presented by Matogoro J 18
 A04:2021-Insecure Design
• Secure Design
– Secure design is a culture and methodology that constantly
evaluates threats and ensures that code is robustly
designed and tested to prevent known attack methods.
– Threat modeling should be integrated into refinement
sessions (or similar activities); look for changes in data
flows and access control or other security controls.
– In the user story development determine the correct flow
and failure states, ensure they are well understood and
agreed upon by responsible and impacted parties.

Presented by Matogoro J 19
 A04:2021-Insecure Design
• Secure Design
– Analyze assumptions and conditions for expected and
failure flows, ensure they are still accurate and desirable.
– Determine how to validate the assumptions and enforce
conditions needed for proper behaviors.
– Ensure the results are documented in the user story.
– Learn from mistakes and offer positive incentives to
promote improvements.
– Secure design is neither an add-on nor a tool that you can
add to software.

Presented by Matogoro J 20
 A04:2021-Insecure Design
• Secure Development Lifecycle
– Secure software requires a secure development lifecycle,
some form of secure design pattern, paved road
methodology, secured component library, tooling, and
threat modeling.
– Reach out for your security specialists at the beginning of a
software project throughout the whole project and
maintenance of your software.
– Consider leveraging the OWASP Software Assurance
Maturity Model (SAMM) to help structure your secure
software development efforts.

Presented by Matogoro J 21
 A05:2021-Security Misconfiguration
• The application might be vulnerable if the
application is:
– Missing appropriate security hardening across any part of the
application stack or improperly configured permissions on
cloud services.
– Unnecessary features are enabled or installed (e.g.,
unnecessary ports, services, pages, accounts, or privileges).
– Default accounts and their passwords are still enabled and
unchanged.
– Error handling reveals stack traces or other overly
informative error messages to users.

Presented by Matogoro J 22
 A05:2021-Security Misconfiguration
• The application might be vulnerable if the application is:
– For upgraded systems, the latest security features are
disabled or not configured securely.
– The security settings in the application servers, application
frameworks (e.g., Struts, Spring, ASP.NET), libraries,
databases, etc., are not set to secure values.
– The server does not send security headers or directives, or
they are not set to secure values.
– The software is out of date or vulnerable.
• Without a concerted, repeatable application security
configuration process, systems are at a higher risk.

Presented by Matogoro J 23
 A06:2021-Vulnerable and Outdated
Components
• You are likely vulnerable:
– If you do not know the versions of all components you use
(both client-side and server-side). This includes
components you directly use as well as nested
dependencies.
– If the software is vulnerable, unsupported, or out of date.
This includes the OS, web/application server, database
management system (DBMS), applications, APIs and all
components, runtime environments, and libraries.
– If you do not scan for vulnerabilities regularly and
subscribe to security bulletins related to the components
you use.
Presented by Matogoro J 24
 A06:2021-Vulnerable and Outdated
Components
• You are likely vulnerable:
– If you do not fix or upgrade the underlying platform,
frameworks, and dependencies in a risk-based, timely
fashion. This commonly happens in environments when
patching is a monthly or quarterly task under change
control, leaving organizations open to days or months of
unnecessary exposure to fixed vulnerabilities.
– If software developers do not test the compatibility of
updated, upgraded, or patched libraries.
– If you do not secure the components’ configurations
(see A05:2021-Security Misconfiguration).

Presented by Matogoro J 25
 A07:2021-Identification and
Authentication Failures
• Confirmation of the user's identity, authentication, and
session management is critical to protect against
authentication-related attacks. There may be authentication
weaknesses if the application:
• Permits automated attacks such as credential stuffing, where
the attacker has a list of valid usernames and passwords.
• Permits brute force or other automated attacks.
• Permits default, weak, or well-known passwords, such as
"Password1" or "admin/admin".

Presented by Matogoro J 26
 A07:2021-Identification and
Authentication Failures
• Uses weak or ineffective credential recovery and forgot-
password processes, such as "knowledge-based answers,"
which cannot be made safe.
• Uses plain text, encrypted, or weakly hashed passwords data
stores (see A02:2021-Cryptographic Failures).
• Has missing or ineffective multi-factor authentication.
• Exposes session identifier in the URL.
• Reuse session identifier after successful login.
• Does not correctly invalidate Session IDs. User sessions or
authentication tokens (mainly single sign-on (SSO) tokens)
aren't properly invalidated during logout or a period of
inactivity.
Presented by Matogoro J 27
 A08:2021-Software and Data
Integrity Failures
• 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.
Presented by Matogoro J 28
 A08:2021-Software and Data
Integrity Failures
• 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.
Presented by Matogoro J 29
 A09:2021-Security Logging and
Monitoring Failures
• Returning to the OWASP Top 10 2021, this category is to help
detect, escalate, and respond to active breaches. Without
logging and monitoring, breaches cannot be detected.
Insufficient logging, detection, monitoring, and active
response occurs any time:
• Auditable events, such as logins, failed logins, and high-value
transactions, are not logged.
• Warnings and errors generate no, inadequate, or unclear log
messages.
• Logs of applications and APIs are not monitored for suspicious
activity.

Presented by Matogoro J 30
 A09:2021-Security Logging and
Monitoring Failures
• Logs are only stored locally.
• Appropriate alerting thresholds and response escalation
processes are not in place or effective.
• Penetration testing and scans by dynamic application security
testing (DAST) tools (such as OWASP ZAP) do not trigger
alerts.
• The application cannot detect, escalate, or alert for active
attacks in real-time or near real-time.
• You are vulnerable to information leakage by making logging
and alerting events visible to a user or an attacker
(see A01:2021-Broken Access Control).

Presented by Matogoro J 31
 A10:2021-Server-Side Request
Forgery
• SSRF flaws occur whenever a web application is fetching a
remote resource without validating the user-supplied URL.
• It allows an attacker to coerce the application to send a
crafted request to an unexpected destination, even when
protected by a firewall, VPN, or another type of network
access control list (ACL).
• As modern web applications provide end-users with
convenient features, fetching a URL becomes a common
scenario.
• As a result, the incidence of SSRF is increasing.
• Also, the severity of SSRF is becoming higher due to cloud
services and the complexity of architectures.
Presented by Matogoro J 32
 Reference
• https://owasp.org/Top10/

Presented by Matogoro J 33