The document summarizes the evolution of the Java security model from JDK 1.0 to the current version. It discusses how the security model started with a simple trusted/untrusted code separation and gradually evolved to support signed applets, fine-grained access control, and role-based access using JAAS. It also discusses how the security model will be applied to modules in future versions. Additionally, it covers some of the key security APIs available outside the sandbox like JCA, PKI, JSSE, and best practices for secure coding.
Martin Toshev - Java Security Architecture - Codemotion Rome 2019Codemotion
The session provides an overview of the security architecture of the Java platform in terms of its evolution throughout the versions of the JDK up to JDK 11 and beyond. The security utilities that fullfill the security portfolio of the JDK will be discussed briefly along with several guidelines in designing and implementing secure applications by following security best practices.
Public REST APIs have become mainstream. Now, almost every company that wants to expose services or an application programming interface does it using a publicly exposed REST API. This talk will give participants the skills they need to identify and understand REST vulnerabilities. The findings are a result of reviewing production REST applications as well as researching popular REST frameworks.
By Dinis Cruz, Abraham Kang and Alvaro Muñoz
Martin Toshev - Java Security Architecture - Codemotion Rome 2019Codemotion
The session provides an overview of the security architecture of the Java platform in terms of its evolution throughout the versions of the JDK up to JDK 11 and beyond. The security utilities that fullfill the security portfolio of the JDK will be discussed briefly along with several guidelines in designing and implementing secure applications by following security best practices.
Public REST APIs have become mainstream. Now, almost every company that wants to expose services or an application programming interface does it using a publicly exposed REST API. This talk will give participants the skills they need to identify and understand REST vulnerabilities. The findings are a result of reviewing production REST applications as well as researching popular REST frameworks.
By Dinis Cruz, Abraham Kang and Alvaro Muñoz
Surviving the Java Deserialization Apocalypse // OWASP AppSecEU 2016Christian Schneider
The hidden danger of Java deserialization vulnerabilities – which often lead to remote code execution – has gained extended visibility in the past year. The issue has been known for years; however, it seems that the majority of developers were unaware of it until recent media coverage around commonly used libraries and major products. This talk aims to shed some light about how this vulnerability can be abused, how to detect it from a static and dynamic point of view, and -- most importantly -- how to effectively protect against it. The scope of this talk is not limited to the Java serialization protocol but also other popular Java libraries used for object serialization.
The ever-increasing number of new vulnerable endpoints and attacker-usable gadgets has resulted in a lot of different recommendations on how to protect your applications, including look-ahead deserialization and runtime agents to monitor and protect the deserialization process. Coming at the problem from a developer’s perspective and triaging the recommendations for you, this talk will review existing protection techniques and demonstrate their effectiveness on real applications. It will also review existing techniques and present new gadgets that demonstrates how attackers can actually abuse your application code and classpath to craft a chain of gadgets that will allow them to compromise your servers.
This talk will also present the typical architectural decisions and code patterns that lead to an increased risk of exposing deserialization vulnerabilities. Mapping the typical anti-patterns that must be avoided, through the use of real code examples we present an overview of hardening techniques and their effectiveness. The talk will also show attendees what to search the code for in order to find potential code gadgets the attackers can leverage to compromise their applications. We’ll conclude with action items and recommendations developers should consider to mitigate this threat.
--
This talk was presented by Alvaro Muñoz & Christian Schneider at the OWASP AppSecEU 2016 conference in Rome.
MyFaces CODI and JBoss Seam3 become Apache DeltaSpikeos890
These slides show how to use type-safe mechanisms provided by MyFaces CODI for developing JSF applications which are more type-safe and easier to maintain as well as common pitfalls. Beyond that there is an basic overview of Apache DeltaSpike.
Defending against Java Deserialization VulnerabilitiesLuca Carettoni
Java deserialization vulnerabilities have recently gained popularity due to a renewed interest from the security community. Despite being publicly discussed for several years, a significant number of Java based products are still affected. Whenever untrusted data is used within deserialization methods, an attacker can abuse this simple design anti-pattern to compromise your application. After a quick introduction of the problem, this talk will focus on discovering and defending against deserialization vulnerabilities. I will present a collection of techniques for mitigating attacks when turning off object serialization is not an option, and we will discuss practical recommendations that developers can use to help prevent these attacks.
Unsafe Deserialization Attacks In Java and A New Approach To Protect The JVM ...Apostolos Giannakidis
This talk provides an introduction and detailed overview of Java deserialization attacks. You will understand the basic concepts of how Java deserialization exploits (gadget chains) work, what solutions exist and the advantages and disadvantages of each. Finally, a new approach will be presented, using Runtime Virtualization, Compartmentalization and Privilege De-escalation.
This talk was presented by Apostolos Giannakidis at the OWASP London meetup on May 2017.
Slides for my Devoxx tools-in-action speech. Basics of Java Security Manager are covered there. A new library called pro-grade which helps to keep your life with java security easy is introduced.
From previously developed a simple web application (based on X-Files tv series) the aim will be to set both user authentication and authorization of web resources both for themselves and for the invocation of business components. It’ll be established a minimum security settings, which will be completed with more sophisticated mechanisms. All of these emphasizing the novelties of version 3.x of Spring Security as the use of SPEL, Annotations, Namespace, Java config, etc. Attendees will see many of the features that implements Spring Security to set security mechanisms within JEE applications. The tools to be used are Spring Tool Suite 3.4, Springframework 3.2, Maven 3 and Spring Tc Server 2.9.
Make JSF more type-safe with CDI and MyFaces CODIos890
These slides show how to use type-safe mechanisms provided by MyFaces CODI for developing JSF applications which are more type-safe and easier to maintain.
http://2012.con-fess.com/sessions/-/details/136/MyFaces-CODI-and-JBoss-Seam3-become-Apache-DeltaSpike is the next part with more details about MyFaces CODI and Apache DeltaSpike at
Surviving the Java Deserialization Apocalypse // OWASP AppSecEU 2016Christian Schneider
The hidden danger of Java deserialization vulnerabilities – which often lead to remote code execution – has gained extended visibility in the past year. The issue has been known for years; however, it seems that the majority of developers were unaware of it until recent media coverage around commonly used libraries and major products. This talk aims to shed some light about how this vulnerability can be abused, how to detect it from a static and dynamic point of view, and -- most importantly -- how to effectively protect against it. The scope of this talk is not limited to the Java serialization protocol but also other popular Java libraries used for object serialization.
The ever-increasing number of new vulnerable endpoints and attacker-usable gadgets has resulted in a lot of different recommendations on how to protect your applications, including look-ahead deserialization and runtime agents to monitor and protect the deserialization process. Coming at the problem from a developer’s perspective and triaging the recommendations for you, this talk will review existing protection techniques and demonstrate their effectiveness on real applications. It will also review existing techniques and present new gadgets that demonstrates how attackers can actually abuse your application code and classpath to craft a chain of gadgets that will allow them to compromise your servers.
This talk will also present the typical architectural decisions and code patterns that lead to an increased risk of exposing deserialization vulnerabilities. Mapping the typical anti-patterns that must be avoided, through the use of real code examples we present an overview of hardening techniques and their effectiveness. The talk will also show attendees what to search the code for in order to find potential code gadgets the attackers can leverage to compromise their applications. We’ll conclude with action items and recommendations developers should consider to mitigate this threat.
--
This talk was presented by Alvaro Muñoz & Christian Schneider at the OWASP AppSecEU 2016 conference in Rome.
MyFaces CODI and JBoss Seam3 become Apache DeltaSpikeos890
These slides show how to use type-safe mechanisms provided by MyFaces CODI for developing JSF applications which are more type-safe and easier to maintain as well as common pitfalls. Beyond that there is an basic overview of Apache DeltaSpike.
Defending against Java Deserialization VulnerabilitiesLuca Carettoni
Java deserialization vulnerabilities have recently gained popularity due to a renewed interest from the security community. Despite being publicly discussed for several years, a significant number of Java based products are still affected. Whenever untrusted data is used within deserialization methods, an attacker can abuse this simple design anti-pattern to compromise your application. After a quick introduction of the problem, this talk will focus on discovering and defending against deserialization vulnerabilities. I will present a collection of techniques for mitigating attacks when turning off object serialization is not an option, and we will discuss practical recommendations that developers can use to help prevent these attacks.
Unsafe Deserialization Attacks In Java and A New Approach To Protect The JVM ...Apostolos Giannakidis
This talk provides an introduction and detailed overview of Java deserialization attacks. You will understand the basic concepts of how Java deserialization exploits (gadget chains) work, what solutions exist and the advantages and disadvantages of each. Finally, a new approach will be presented, using Runtime Virtualization, Compartmentalization and Privilege De-escalation.
This talk was presented by Apostolos Giannakidis at the OWASP London meetup on May 2017.
Slides for my Devoxx tools-in-action speech. Basics of Java Security Manager are covered there. A new library called pro-grade which helps to keep your life with java security easy is introduced.
From previously developed a simple web application (based on X-Files tv series) the aim will be to set both user authentication and authorization of web resources both for themselves and for the invocation of business components. It’ll be established a minimum security settings, which will be completed with more sophisticated mechanisms. All of these emphasizing the novelties of version 3.x of Spring Security as the use of SPEL, Annotations, Namespace, Java config, etc. Attendees will see many of the features that implements Spring Security to set security mechanisms within JEE applications. The tools to be used are Spring Tool Suite 3.4, Springframework 3.2, Maven 3 and Spring Tc Server 2.9.
Make JSF more type-safe with CDI and MyFaces CODIos890
These slides show how to use type-safe mechanisms provided by MyFaces CODI for developing JSF applications which are more type-safe and easier to maintain.
http://2012.con-fess.com/sessions/-/details/136/MyFaces-CODI-and-JBoss-Seam3-become-Apache-DeltaSpike is the next part with more details about MyFaces CODI and Apache DeltaSpike at
Writing Java Stored Procedures in Oracle 12cMartin Toshev
The session discusses the innerworkings ot the Oracle Aurora JVM, the process of writing and maintaining Java stored procedures and the new features in Oracle database 12c.
Introductory presentation for the Clash of Technologies: RxJS vs RxJava event organized by SoftServe @ betahouse (17.01.2015). Comparison document with questions & answers available here: https://docs.google.com/document/d/1VhuXJUcILsMSP4_6pCCXBP0X5lEVTsmLivKHcUkFvFY/edit#.
Eclipse plug-in development seminar held by the Bulgarian Java User group covering basic aspects of Eclipse plug-in development and the new stuff in e4
The session presents in the details the RabbitMQ message broker along with demonstrations using the Java client, the Spring integration for RabbitMQ and the administration tools provided as part of the RabbitMQ installation.
The feature we always hear about whenever Java 9 is in the news is Jigsaw, modularity. But this doesn't scratch the
same developer itch that Java 8's lambdas and streams did, and we're left with a vague sensation that the next version might not be that interesting.
Java 9 actually has a lot of great additions and changes to make development a bit nicer. These features can't be lumped under an umbrella term like Java 8's lambdas and streams, the changes are scattered throughout the APIs and language features that we regularly use.
In this presentation Trisha will show, via live coding:
- How we can use the new Flow API to utilise Reactive Programming
- How the improvements to the Streams API make it easier to control real-time streaming data
- How to the Collections convenience methods simplify code
Along the way we'll bump into other Java 9 features, including some of the additions to interfaces and changes to deprecation. We’ll see that once you start using Java 9, you can't go back to Before.
Presentation on the new features introduced in JDK 8, presented on the 26.02.2013 in Sofia University in front of students and members of the Bulgarian java user group.
Que es Spring Security
Arquitectura de Spring Security
Configuraciones:
Modulos de spring security en maven
web.xml
securityContext.xml
applicationContext.xml
AuthenticationProvider.java
Login.xhtml
ManageBean login
In this session I will present best practices of how open source tools (used in the DevOps and security communities) can be properly chained together to form a framework that can - as part of an agile software development CI chain - perform automated checking of certain security aspects. This does not remove the requirement for manual pentests, but tries to automate early security feedback to developers.
Based on my experience of applying SecDevOps techniques to projects, I will present the glue steps required on every commit and at nightly builds to achieve different levels of depth in automated security testing during the CI workflow.
I will conclude with a "SecDevOps Maturity Model" of different stages of automated security testing and present concrete examples of how to achieve each stage with open source security tools.
Securing Microservices using Play and Akka HTTPRafal Gancarz
Going down the microservices route makes a lot of things around creating and maintaining large systems easier but it comes at a cost too, particularly associated with challenges around security. While securing monolithic applications was a relatively well understood area, the same can't be said about microservice based architectures.
This presentation covers how implementing microservices affects the security of distributed systems, outlines pros and cons of several standards and common practices and offers practical suggestions for securing microservice based systems using Play and Akka HTTP.
CDI and Seam 3: an Exciting New Landscape for Java EE DevelopmentSaltmarch Media
CDI (Contexts and Dependency Injection) for Java, aka JSR-299 has given us a new playing field for developing Java EE applications, by providing a standardised dependency injection framework and contextual component model. The CDI specification defines a feature for "portable extensions", which allow framework developers to extend the default behaviour of the Java EE container. By providing a number of useful portable extensions, Seam 3 increases developer productivity by solving the problems common to many enterprise projects. In this talk we will look at a number of features that Seam provides, dealing with transactions and persistence, security, internationalisation, bean validation and tooling, and how you can use them to improve your productivity in the real-world to develop rich internet applications. We'll also look at some of the cool upcoming features of Seam such as social network integration, and more.
Thi presentation is about -
SSL Concepts,
Configure SSL between IHS and WAS,
The ikeyman tool,
For more details visit -
http://vibranttechnologies.co.in/websphere-classes-in-mumbai.html
How do JavaScript frameworks impact the security of applications?Ksenia Peguero
The best way to enable developers to create secure applications is to “shift left” in security. That means providing developers with the tools and techniques that help build more secure applications from the get-go. Developers may get security controls into their applications in different ways. They may write them from scratch following security training or guidance, they may use open source libraries, or they may use frameworks that have the security features built in already. In this talk we explore JavaScript applications that use different types of security controls implemented at levels ranging from developer code, to libraries and plugins, to different frameworks, and analyze which applications actually turn out to be more secure. This work is based on analysis of over 500 open source JavaScript applications on GitHub that use client-side frameworks and template engines to prevent XSS, as well as server-side frameworks (Express, Koa, Hapi, Sails, Meteor) and CSRF prevention mechanisms. In conclusion, we provide data-driven recommendations for framework maintainers and application developers on how to develop and choose a framework that will actually make applications more secure.
Security DevOps - Free pentesters' time to focus on high-hanging fruits // Ha...Christian Schneider
In this session I will present best practices of how open source tools (used in the DevOps and security communities) can be properly chained together to form a framework that can - as part of an agile software development CI chain - perform automated checking of certain security aspects. This does not remove the requirement for manual pentests, but tries to automate early security feedback to developers. Ultimately the aim is to free pentesters’ time by continuously reducing the amount of
recurring (easy to find) default findings, so that pentesters can use
that time to focus on the really high-hanging fruits.
Based on my experience of applying SecDevOps techniques to projects, I will present the glue steps required on every commit and at nightly builds to achieve different levels of depth in automated security testing during the CI workflow.
I will conclude with a "SecDevOps Maturity Model" of different stages of automated security testing and present concrete examples of how to achieve each stage with open source security tools.
Similar to Security Аrchitecture of Тhe Java Platform (20)
Modularity of the Java Platform (OSGi, Jigsaw and Penrose)Martin Toshev
Seminar "Modularity of the Java Platform" of the Bulgarian Java User Group.
Topics of the seminar:
Modularity 101
Modularity on top of the platform: OSGi
Modularity of the platform: Jigsaw
OSGi and Jigsaw interoperability: Penrose
State of ICS and IoT Cyber Threat Landscape Report 2024 previewPrayukth K V
The IoT and OT threat landscape report has been prepared by the Threat Research Team at Sectrio using data from Sectrio, cyber threat intelligence farming facilities spread across over 85 cities around the world. In addition, Sectrio also runs AI-based advanced threat and payload engagement facilities that serve as sinks to attract and engage sophisticated threat actors, and newer malware including new variants and latent threats that are at an earlier stage of development.
The latest edition of the OT/ICS and IoT security Threat Landscape Report 2024 also covers:
State of global ICS asset and network exposure
Sectoral targets and attacks as well as the cost of ransom
Global APT activity, AI usage, actor and tactic profiles, and implications
Rise in volumes of AI-powered cyberattacks
Major cyber events in 2024
Malware and malicious payload trends
Cyberattack types and targets
Vulnerability exploit attempts on CVEs
Attacks on counties – USA
Expansion of bot farms – how, where, and why
In-depth analysis of the cyber threat landscape across North America, South America, Europe, APAC, and the Middle East
Why are attacks on smart factories rising?
Cyber risk predictions
Axis of attacks – Europe
Systemic attacks in the Middle East
Download the full report from here:
https://sectrio.com/resources/ot-threat-landscape-reports/sectrio-releases-ot-ics-and-iot-security-threat-landscape-report-2024/
GraphRAG is All You need? LLM & Knowledge GraphGuy Korland
Guy Korland, CEO and Co-founder of FalkorDB, will review two articles on the integration of language models with knowledge graphs.
1. Unifying Large Language Models and Knowledge Graphs: A Roadmap.
https://arxiv.org/abs/2306.08302
2. Microsoft Research's GraphRAG paper and a review paper on various uses of knowledge graphs:
https://www.microsoft.com/en-us/research/blog/graphrag-unlocking-llm-discovery-on-narrative-private-data/
Neuro-symbolic is not enough, we need neuro-*semantic*Frank van Harmelen
Neuro-symbolic (NeSy) AI is on the rise. However, simply machine learning on just any symbolic structure is not sufficient to really harvest the gains of NeSy. These will only be gained when the symbolic structures have an actual semantics. I give an operational definition of semantics as “predictable inference”.
All of this illustrated with link prediction over knowledge graphs, but the argument is general.
JMeter webinar - integration with InfluxDB and GrafanaRTTS
Watch this recorded webinar about real-time monitoring of application performance. See how to integrate Apache JMeter, the open-source leader in performance testing, with InfluxDB, the open-source time-series database, and Grafana, the open-source analytics and visualization application.
In this webinar, we will review the benefits of leveraging InfluxDB and Grafana when executing load tests and demonstrate how these tools are used to visualize performance metrics.
Length: 30 minutes
Session Overview
-------------------------------------------
During this webinar, we will cover the following topics while demonstrating the integrations of JMeter, InfluxDB and Grafana:
- What out-of-the-box solutions are available for real-time monitoring JMeter tests?
- What are the benefits of integrating InfluxDB and Grafana into the load testing stack?
- Which features are provided by Grafana?
- Demonstration of InfluxDB and Grafana using a practice web application
To view the webinar recording, go to:
https://www.rttsweb.com/jmeter-integration-webinar
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf91mobiles
91mobiles recently conducted a Smart TV Buyer Insights Survey in which we asked over 3,000 respondents about the TV they own, aspects they look at on a new TV, and their TV buying preferences.
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024Albert Hoitingh
In this session I delve into the encryption technology used in Microsoft 365 and Microsoft Purview. Including the concepts of Customer Key and Double Key Encryption.
UiPath Test Automation using UiPath Test Suite series, part 4DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 4. In this session, we will cover Test Manager overview along with SAP heatmap.
The UiPath Test Manager overview with SAP heatmap webinar offers a concise yet comprehensive exploration of the role of a Test Manager within SAP environments, coupled with the utilization of heatmaps for effective testing strategies.
Participants will gain insights into the responsibilities, challenges, and best practices associated with test management in SAP projects. Additionally, the webinar delves into the significance of heatmaps as a visual aid for identifying testing priorities, areas of risk, and resource allocation within SAP landscapes. Through this session, attendees can expect to enhance their understanding of test management principles while learning practical approaches to optimize testing processes in SAP environments using heatmap visualization techniques
What will you get from this session?
1. Insights into SAP testing best practices
2. Heatmap utilization for testing
3. Optimization of testing processes
4. Demo
Topics covered:
Execution from the test manager
Orchestrator execution result
Defect reporting
SAP heatmap example with demo
Speaker:
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Accelerate your Kubernetes clusters with Varnish CachingThijs Feryn
A presentation about the usage and availability of Varnish on Kubernetes. This talk explores the capabilities of Varnish caching and shows how to use the Varnish Helm chart to deploy it to Kubernetes.
This presentation was delivered at K8SUG Singapore. See https://feryn.eu/presentations/accelerate-your-kubernetes-clusters-with-varnish-caching-k8sug-singapore-28-2024 for more details.
5. Evolution of the
Java security model
• Traditionally - companies protect they assets
using strict physical and network access policies
• Tools such as anti-virus software, firewalls,
IPS/IDS systems facilitate this approach
6. Evolution of the
Java security model
• With the introduction of various technologies for
loading and executing code on the client machine
from the browser (such as Applets) - a new range
of concerns emerge related to client security –
this is when the Java security sandbox starts to
evolve …
7. Evolution of the
Java security model
• The goal of the Java security sandbox is to allow
untrusted code from applets to be executed in a
trusted environment such as the user's browser
8. Evolution of the
Java security model
• JDK 1.0 (when it all started …) – the original
sandbox model was introduced
Applet
(untrusted)
System code
(trusted)
JVM
Browser
http://voxxeddays.com/demoapplet
9. Evolution of the
Java security model
• Code executed by the JVM is divided in two
domains – trusted and untrusted
• Strict restriction are applied by default on the
security model of applets such as denial to
read/write data from disk, connect to the
network and so on
10. Evolution of the
Java security model
• JDK 1.1 (gaining trust …) – applet signing
introduced
Applet
(untrusted)
System code
(trusted)
JVM
Browser
Signed Applet
(trusted)
http://voxxeddays.com/demoapplet
http://voxxeddays.com/trustedapplet
11. Evolution of the
Java security model
• Local code (as in JDK 1.0) and signed applet code
(as of JDK 1.1) are trusted
• Unsigned remote code (as in JDK 1.0) is not
trusted
12. Evolution of the
Java security model
• Steps needed to sign and run an applet:
– Compile the applet
– Create a JAR file for the applet
– Generate a pair of public/private keys
– Sign the applet JAR with the private key
– Export a certificate for the public key
– Import the Certificate as a Trusted Certificate
– Create the policy file
– Load and run the applet
13. Evolution of the
Java security model
• JDK 1.2 (gaining more trust …) – fine-grained
access control
Applet
System code
JVM
Browser
grant codeBase http://voxxeddays.com/demoapplet {
permission java.io.FilePermisions “C:Windows” “delete”
}
security.policy
SecurityManager.checkPermission(…)
AccessController.checkPermission(…)
http://voxxeddays.com/demoapplet
14. Evolution of the
Java security model
• The security model becomes code-centric
• Additional access control decisions are specified
in a security policy
• No more notion of trusted and untrusted code
15. Evolution of the
Java security model
• The notion of protection domain introduced –
determined by the security policy
• Two types of protection domains – system and
application
16. Evolution of the
Java security model
• The protection domain is set during classloading
and contains the code source and the list of
permissions for the class
applet.getClass().getProtectionDomain();
17. Evolution of the
Java security model
• One permission can imply another permission
java.io.FilePermissions “C:Windows” “delete”
implies
java.io.FilePermissions “C:Windowssystem32” “delete”
18. Evolution of the
Java security model
• One code source can imply another code source
codeBase http://voxxeddays.com/
implies
codeBase http://voxxeddays.com/demoapplet
19. Evolution of the
Java security model
• Since an execution thread may pass through
classes loaded by different classloaders (and
hence – have different protection domains) the
following rule of thumb applies:
The permission set of an execution thread is considered
to be the intersection of the permissions of all protection
domains traversed by the execution thread
20. Evolution of the
Java security model
• JDK 1.3, 1,4 (what about entities running the
code … ?) – JAAS
Applet
System code
JVM
Browser
http://voxxeddays.com/demoapplet
grant principal javax.security.auth.x500.X500Principal "cn=Tom"
{ permission java.io.FilePermissions “C:Windows” “delete” }
security.policy
21. Evolution of the
Java security model
• JAAS (Java Authentication and Authorization
Service) extends the security model with role-
based permissions
• The protection domain of a class now may
contain not only the code source and the
permissions but a list of principals
22. Evolution of the
Java security model
• The authentication component of JAAS is
independent of the security sandbox in Java and
hence is typically used in more wider context
(such as j2ee app servers)
• The authorization component is the one that
extends the Java security policy
23. Evolution of the
Java security model
• Core classes of JAAS:
– javax.security.auth.Subject - an authenticated subject
– java.security.Principal - identifying characteristic of a subject
– javax.security.auth.spi.LoginModule - interface for
implementors of login (PAM) modules
– javax.security.auth.login.LoginContext - creates objects used
for authentication
24. Evolution of the
Java security model
• Up to JDK 1.4 the following is a typical flow for
permission checking:
1) upon system startup a security policy is set and a
security manager is installed
Policy.setPolicy(…)
System.setSecurityManager(…)
25. Evolution of the
Java security model
• Up to JDK 1.4 the following is a typical flow for
permission checking:
2) during classloading (e.g. of a remote applet) bytecode
verification is done and the protection domain is set
for the current classloader (along with the code
source, the set of permissions and the set of JAAS
principals)
26. Evolution of the
Java security model
• Up to JDK 1.4 the following is a typical flow for
permission checking:
3) when system code is invoked from the remote code
the SecurityManager is used to check against the
intersection of protection domains based on the chain
of threads and their call stacks
27. Evolution of the
Java security model
• Up to JDK 1.4 the following is a typical flow for
permission checking:
SocketPermission permission = new
SocketPermission("voxxeddays.com:8000-
9000","connect,accept");
SecurityManager sm = System.getSecurityManager();
if (sm != null) sm.checkPermission(permission);
28. Evolution of the
Java security model
• Up to JDK 1.4 the following is a typical flow for
permission checking:
4) application code can also do permission checking
against remote code using a SecurityManager or an
AccessController
29. Evolution of the
Java security model
• Up to JDK 1.4 the following is a typical flow for
permission checking:
SocketPermission permission = new
SocketPermission("voxxeddays.com:8000-9000",
"connect,accept");
AccessController.checkPermission(permission)
30. Evolution of the
Java security model
• Up to JDK 1.4 the following is a typical flow for
permission checking:
5) application code can also do permission checking with
all permissions of the calling domain or a particular
JAAS subject
AccessController.doPrivileged(…)
Subject.doAs(…)
Subject.doAsPrivileged(…)
31. Evolution of the
Java security model
• The security model defined by
java.lang.SecurityManager is customizable
• For example: Oracle JVM uses a custom
SecurityManager with additional permission
classes where the code source is a database
schema (containing e.g. Java stored procedures)
32. Evolution of the
Java security model
• JDK 1.5, 1.6 (enhancing the model …) – new
additions to the sandbox model (e.g. LDAP
support for JAAS)
33. Evolution of the
Java security model
• JDK 1.7, 1.8 (further enhancing the model …) –
enhancements to the sandbox model (e.g.
AccessController.doPrivileged() for checking
against a subset of permissions)
34. Evolution of the
Java security model
• JDK 1.9 and beyond … (applying the model to
modules …)
application module
system
module 1
JVM
Browser
http://voxxeddays.com/appmodule
security.policy
system
module 2
35. Evolution of the
Java security model
• By modules we understand modules in JDK as
defined by project Jigsaw
• Modules must conform to the same security
model as applets – moreover each module is
loaded by a different classloader – hence classes
in different modules must have different
protection domains
36. Evolution of the
Java security model
• Modularization of the JDK system classes
allows further to define fine-grained access
control permissions for classes in the system
domain
• This is not currently allowed due to the
monolithic nature of the JDK
38. Outside the sandbox - APIs for secure
coding
• The security sandbox defines a strict model for
execution of remote code in the JVM
• The other side of the coin are the security APIs
that provide utilities for implementing the
different aspects of application security …
39. Outside the sandbox - APIs for secure
coding
• The additional set of APIs includes:
– JCA (Java Cryptography Architecture)
– PKI (Public Key Infrastructure) utilities
– JSSE (Java Secure Socket Extension)
– Java GSS API (Java Generic Security Services)
– Java SASL API (Java Simple Authentication and Security
Layer)
40. Outside the sandbox - APIs for secure
coding
• JCA provides utilities for:
– creating digital signatures
– creating message digests
– using cryptographic ciphers (symetric/asymetric,
block/stream)
– using different other types of cryptographic services and
algorithms
41. Outside the sandbox - APIs for secure
coding
• JCA has a pluggable architecture
• JCA is independent from particular cryptographic
algorithms
• JCA continues to evolve (especially by providing
stronger cryptographic algorithms)
42. Outside the sandbox - APIs for secure
coding
• PKI utilities provide means for working with:
– certificates
– certificate revocation lists (CRL)
– OCSP (Online Certificate Status Protocol)
– key stores and trust stores (also based on the PKCS -
public-key cryptography standards)
43. Outside the sandbox - APIs for secure
coding
• PKI certificate revocation check (revision):
• PKI utilities continue to evolve (especially in
providing more support for managing certificates
and keys)
certificate
authorityrevocation
checking
OCSP
CRL
certificate
certificate
44. Outside the sandbox - APIs for secure
coding
• JSSE provides an implementation of the TSL/SSL
sockets for working with remote communication
• JSSE continues to evolve (especially in the
support for additional features such as Server
Name Identication)
45. Outside the sandbox - APIs for secure
coding
• Java GSS API provides an alternative of JSSE
for secure communication
• Java GSS API is a framework for providing
token-based security services that is
independent of the underlying protocols
46. Outside the sandbox - APIs for secure
coding
• Java GSS API can be used along with JAAS for
authentication purposes
• Java GSS API continues to evolve (especially in
the support for Kerberos authentication)
47. Outside the sandbox - APIs for secure
coding
• Java SASL defines a protocol for exchange of
authentication data
• Java SASL is a framework where external
providers give concrete semantics to the
authentication data being exchanged
48. Outside the sandbox - APIs for secure
coding
• Java SASL continues to evolve (especially with
support for additional and enhanced
properties for exchanging authentication data)
50. Designing and coding
with security in mind
• First of all - follow programing guidelines and
best practices - most are not bound to the Java
programming language (input validation, error
handling, type safety, access modifiers, resource
cleanup, prepared SQL queries and whatever you
can think of …)
51. Designing and coding
with security in mind
• Respect the SecurityManager - design libraries so
that they work in environments with installed
SecurityManager
• Example: GSON library does not respect the
SecurityManager and cannot be used without additional
reflective permissions in some scenarios
52. Designing and coding
with security in mind
• Grant minimal permissions to code that requires
them - the principle of "least privilege"
• Copy-pasting, of course, increases the risk of
security flows (if the copied code is flawed)
53. Designing and coding
with security in mind
• Sanitize exception messages from sensitive
information - often this results in an unintended
exposal of exploitable information
• Let alone exception stacktraces … in many cases
they convey a wealth of information about the
system
58. References
• Core Java Security: Class Loaders, Security
Managers and Encryption
http://www.informit.com/articles/article.aspx?p=118796
7
• Overview of Java Security Models
http://docs.oracle.com/cd/E12839_01/core.1111/e1004
3/introjps.htm#CHDCEJGH
Editor's Notes
The code source on the other hand contains the URL location, the list of signers and the list of certificates
The code source on the other hand contains the URL location, the list of signers and the list of certificates
The code source on the other hand contains the URL location, the list of signers and the list of certificates
The code source on the other hand contains the URL location, the list of signers and the list of certificates
The code source on the other hand contains the URL location, the list of signers and the list of certificates
A typical scenario – in a single multiuser operating system we may have multiple users accessing the same applet from the browser – we may want to define permissions based on the currently logged-in user by providing integration with e.g. Kerberos (in case of a Windows OS)
An AccessControlContext keeps the list of protection domains for the current thread
An AccessControlContext keeps the list of protection domains for the current thread
There are two main differences in using a SecurityManager and an AccessController:
The SecurityManager needs to be installed while AccessController only provides static methods
The SecurityManager can be customized while AccessController provides additional algorithms that can be used over the default security model
There are two main differences in using a SecurityManager and an AccessController:
The SecurityManager needs to be installed while AccessController only provides static methods
The SecurityManager can be customized while AccessController provides additional algorithms that can be used over the default security model
Calling code with a different JAAS subject is similar to the Unix setuid utility