Seven perilous pitfalls to avoid with Java | DevNation Tech Talk

@spoole167
7 Perilous Pitfalls with Java 2020

@spoole167
This Session is about Java
security
• It’s about how to start thinking
about secure application design
• It’s about how to improve your
development processes
• It’s about why this really matters
• It’s a taster only
There’s not much Java in it..

@spoole167
Software design flaws are grouped into “7 Pernicious Kingdoms”

@spoole167
A bit of a marketing
exercise
• 2005 Fortify Software released a
paper called
“Seven Pernicious Kingdoms: A
Taxonomy of Software Security
Errors”
• It caught on among the security
community

@spoole167
In fact there are more than 7
☺

@spoole167
Seven
Pernicious
Kingdoms
Security Features
Time and State
Errors
Input Validation and Representation
API Abuse
Code Quality
Encapsulation
Environment

@spoole167
Seven
Perilous
Pitfalls
For Java
Security Features
Time and State
Errors
API Abuse
Code Quality
Encapsulation
Environment

@spoole167
Agenda
Using real scenarios
and other examples
dip into the 7PK
looking at code and
thinking about design

@spoole1679
Pitfall 0 :Believing the fake
news…

@spoole167
All You need is a firewall

@spoole167
Internet
network
cluster
Server
Container……………………application
Reality
Do you think just a firewall is sufficient?

@spoole167
Internet
network
cluster
Server
Reality
Bad guys are looking for exploits
everywhere
Vulnerabilities in the application
Vulnerabilities in the container
Vulnerabilities in the server
Vulnerabilities in the cluster
Vulnerabilities in the network

@spoole167
Internet
network
cluster
Server
Reality
Your best defense
✓ Defense in depth
✓ Detection
Forsooth we
are under
attack my
liege

@spoole167
First scenario
• I’m developing a performance tool for
Adopt OpenJDK
• It’s designed to run locally but will
eventually be hostable

@spoole167
Browser Server
Docker
Daemon
Remote
repositories
Local
repositories
WS
Cmd line
http
Adopt Server
http

@spoole167
Problems caused by metacharacters, alternate encodings and
numeric representations. General security problems result from
trusting input.

@spoole167
Forms Input.
1. Browser javascript code validates the form
2. Send the data to the server over a websocket as JSON.
3. Server turns JSON into Java
Browser Server
WS
http

@spoole167
My application only expects local war files to be loaded…
‘file://dir/app.war’

@spoole167
My application only expects local war files to be loaded…
‘http://badserver.com/badapp.war’
What happens if I get this?

@spoole167
Pretty obviously you cannot ever
trust what a client sends you. Ever.
Browser Server

@spoole167
Input from an end point is an obvious place to be cautious
Think of it like this…
Every API you write OR call. Whether REST interface or a simple class. Is
a ‘contract’
If that contract is not explicit and enforced your code is vulnerable.
Input Validation and Representation “It is the callers responsibility”

@spoole167
Browser Server
Docker
Daemon
Remote
repositories
Local
repositories
WS
Cmd line
http
Adopt Server
http
My tool uses the docker command line interface to retrieve information and run containers
“docker images”
“docker run –it ubuntu /bin/bash”

@spoole167
public class Driver {
private static final String DEFAULT_EXEC = "/usr/local/bin/docker";
private boolean error;
private String docker;
private File outputFile;
private List results=new LinkedList();
public Driver() {
this(DEFAULT_EXEC);
}
public Driver(String driver) {
docker = driver;
outputFile = new File("/tmp/docker.out");
}
Path to the docker exe
Where to put the output

@spoole167
Driver driver = new Driver();
…
List l = driver.run(“ps –a”);
if (driver.hasError() == false) {
System.out.println(l);
}
public Driver() {
this(DEFAULT_EXEC);
}
docker = driver;
}

@spoole167
What’s wrong with this code?
public Driver() {
this(DEFAULT_EXEC);
}
docker = driver;
}

@spoole167
This field is never validated.
Does it really point to a docker executable?
What would happen if it was set to some
other executable?
Could simply run a version check on it!
“docker –version”
public Driver() {
this(DEFAULT_EXEC);
}
docker = driver;
}

@spoole167
Even if the field was validated
during construction it can still be
changed afterwards.
Relying on constructor validation
only is also poor practise.
(Re)validate before usage
public Driver() {
this(DEFAULT_EXEC);
}
docker = driver;
}

@spoole167
What about this field?
Set to “/tmp/docker.out” ?
public Driver() {
this(DEFAULT_EXEC);
}
docker = driver;
}

@spoole167
What validation does
Java.io.File do?
public Driver() {
this(DEFAULT_EXEC);
}
docker = driver;
}

@spoole167
public File(String pathname) {
if (pathname == null) {
throw new NullPointerException();
}
this.path = fs.normalize(pathname);
this.prefixLength = fs.prefixLength(this.path);
}
private static final FileSystem fs = DefaultFileSystem.getFileSystem();
“A normal Win32 pathname contains no duplicate slashes,
except possibly for a UNC prefix, and does not end with a slash.
It may be the empty string. Normalized Win32 pathnames have
the convenient property that the length of the prefix almost
uniquely identifies the type of the path and whether it is
absolute or relative”
What validation does
Java.io.File do?
- Not much!

@spoole167
File f=new File("../../../../../../../../../../../../../../../../etc/passwd");
System.out.println(f);
Path p=f.toPath();
System.out.println(p);
Path q=p.toRealPath(LinkOption.NOFOLLOW_LINKS);
System.out.println(q);
../../../../../../../../../../../../../../../../etc/passwd
../../../../../../../../../../../../../../../../etc/passwd
/etc/passwd
Code
Output
Takeaway Validation is always your problem

@spoole167
Who uses Java serialization?

@spoole167
Who uses Java serialization?
Do you use RMI, JMX, JMS, Spring Service Invokers?

@spoole167
XMLEncoder (XML)
XStream (XML/JSON/various)
Kryo (binary)
Hessian/Burlap (binary/XML)
Castor (XML)
json-io (JSON)
Jackson (JSON)
Fastjson (JSON)
Red5 IO AMF (AMF)
Apache Flex BlazeDS (AMF)
Flamingo AMF (AMF)
GraniteDS (AMF)
WebORB for Java (AMF)
SnakeYAML (YAML)
jYAML (YAML)
YamlBeans (YAML)
How about one of these?

@spoole167
Any place you rely on:
persistence, messaging, remote ejb
rmi / jmx , rmi-iiop, CDI
There’s some form of serialization going on.

@spoole167
public class LayerCake {
private int layers;
public LayerCake(int layers) {
if(layers<1 || layers > 3)
throw new IllegalArgumentException("number of layers is invalid");
this.layers=layers;
}
Constructors do not get called
During deserialisation
So I can make this value anything I want
What the bad guys do

@spoole167
https://github.com/GrrrDog/Java-Deserialization-Cheat-Sheet
What the good and bad guys do

@spoole167
With serialisation vulnerabilities I
may be able to get the code to
overwrite a critical file somewhere
else.
If I modify both the exe and file
fields I can control what data gets
written to your system
public Driver() {
this(DEFAULT_EXEC);
}
docker = driver;
}
Remember, constructors are not
called during deserialization. The
data is simply inserted.

@spoole167
Protecting yourself
against serialization
exploits is hard
And remember – it’s not
just your code.
Its all your dependencies
too!
Another talk

@spoole167
#1: all data received must be considered
untrusted and potentially dangerous.
• Data means anything that
comes in – command lines,
env variables, sockets, GUI,
REST , even data coming
from your own server…
• You must never trust the
systems who send you data.
• You can almost never trust
the systems you retrieve
data from
• You must validate data
when you get it AND before
you use it

@spoole167
Using an API in a manner contrary to its intended use
API Abuse

@spoole167
API Abuse
My tool tags all the
containers it creates with
“adoptopenjdk=true”
That makes it easier to
retrieve only the relevant
containers when talking to
docker.
I have a test to check I can
create such containers
String id = createSimpleContainer(TEST_IMAGE_NAME);
ContainerInfo ci=inspectContainer(id);
assertTrue(ci.labels().containsKey(“adoptopenjdk”);

@spoole167
API Abuse
But I want to make sure
that the calls to docker are
really working.
So I have a ‘get all’ method.
It’s not used in production
But its exposed as a test
end point…
String id = createSimpleContainer(TEST_IMAGE_NAME);
List<Container> allc = allContainerList();
assertTrue(allc.isEmpty()==false);
get("/test/v1/*" , (req, res) ->plimsoll.test_v1_request.handleRequest(req,res));

@spoole167
API Abuse
A common vulnerability pattern is to find hidden end points like ones just for
testing.
Reading the code on github or just Googling for your sites metadata can easily
reveal them
And of course test end points tend to have less security 
Never have APIs that are just for ‘testing’ or bypass normal
authentication processes..

@spoole167
Google search: intitle:index.of WEB-INF
I found something…

@spoole167
<servlet>
<servlet-name>TestRetrieveFileResponseServlet</servlet-name>
<display-name>TestRetrieveFileResponseServlet</display-name>
<servlet-
class>tests.webservices.TestRetrieveFileResponseServlet</servlet-class>
</servlet>
servlet-mapping>
<servlet-name>TestRetrieveFileResponseServlet</servlet-name>
<url-pattern>/TestRetrieveFileResponseServlet</url-pattern>
</servlet-mapping>
<servlet-mapping>
So I called it

@spoole167
API Abuse
My tool allows for complex scenarios to be created.
JVM = Hotspot or OpenJ9
App Server = Tomcat or Jetty
Various versions strings.
The combinations are sent one by one…
JVM=Hotspot, AppServer=Tomcat, AppVersion=9.0

@spoole167
API Abuse
The code validates the entries as being
individually
correct..
✓ JVM=Hotspot
✓ AppServer=Tomcat
✓ AppVersion=9.4.9
But not that the combinations are valid!

@spoole167
API Abuse
My code also returns lists of containers so there
are page / page size type parameters..
“list containers from page 7 with page size 100”

@spoole167
API Abuse
My code also returns lists of containers so there
are page / page size type parameters..
What about..
“list containers from page 0 with page size -100”
“list containers from page -1 with page size 10”
“list containers from page MAX_INT with page size -MAX_INT”

55
Try likely entry points and all the http verbs
GET /users/1
DELETE /api/v1/users/1
OPTIONS /api/v1/user/1
HEAD /api/v1/user/1
POST /users/1

56
Play with the headers and cookies
POST /api/v1/user HTTP/1.1
Host: developer.mozilla.org
Content-Length: 64
Content-Type: application/x-
www-form-urlencoded

57
Can I get the service to fail or break?
404 “Not Found”
503 “Service Unavailable”
“500 Internal Server Error”
Different errors from different components?

58
If I can find a static endpoint
service I might be able to get
at the filesystem…
GET /api/v1/images/a/../../../../../../etc/passwd

59
Fuzzing calls and data..
GET /users/1
POST /users/2
PUT /users/20000?name=“(select
GET /users/-1
GET /users/$INT_MAX

61
Fuzzing calls and data.
Fuzz urls, json payloads, xml payloads, binary payloads …
Import / export / upload / download options ..
Command line options, file formats …
“known-to-be-dangerous” values
In the public domain
Widespread
& mature
Automatic ‘protocol’
detection & exploitation

@spoole167
#2 Never give control to the
caller by accepting
unconstrained instructions
• Calling endpoints that are
hidden
• Finding hidden fields in your
requests and changing them
• Sending unexpected but
pseudo-valid combinations of
data
• Exploring the data ranges (+
and - )
• Using an API out of context.
(like credit card validation)
• Exploiting query languages
(SQL injection plus. JQ, or
Xpath etc)
• most systems assume any call
to it is correct and do minimal
validation once the individual
elements are accepted.
API Abuse

@spoole167
Errors
Errors related to error handling

@spoole167
Errors
private Properties loadConfig() {
Properties p = new Properties( System.getProperties() );
File f = new File("plimsoll.properties");
if (f.exists()) {
FileReader fr;
try {
fr = new FileReader(f);
p.load(fr);
fr.close();
} catch (IOException e) {
}
return p;
}
Some code – reads a
config file…

@spoole167
Errors
if (f.exists()) {
FileReader fr;
try {
p.load(fr);
fr.close();
}
return p;
}
Don’t assume that only
the errors you expect will
occur - such as
FileNotFoundException

@spoole167
Errors
if (f.exists()) {
FileReader fr;
try {
p.load(fr);
fr.close();
} catch (FileNotFoundException e) {
// allowed
// not expected
}
return p;
}
Better!

@spoole167
Errors
Catching or throwing exceptions in a more generic manner than needed can hide
the activities of the attacker
Either because of a lack of specific info in logging and log analysis
i.e: “Config file not found”. Vs “Unexpected IO Error reading the config file”
Or simply because the unusual exception is treated as usual

@spoole167
Errors
Catching or throwing exceptions in a more generic manner than needed can hide
the activities of the attacker
Either because of a lack of specific info in logging and log analysis
i.e: “Config file not found”. Vs “Unexpected IO Error reading the config file”
Or simply because the unusual exception is treated as usual
BTW - catching NullPointer Exceptions as a way of detecting ‘expected’ nulls is also
poor practice – as described above. You simply can’t tell which NPE is which.

@spoole167
<account>
<name>
Mega Corp Limited
</name>
<address>
The Citadel
London
SW1
</address>
<balance amount="100" currency="EURO"/>
</account>
You have some XML

@spoole167
<account>
<name>
Mega Corp Limited
</name>
<address>
The Citadel
London
SW1
</address>
<balance amount="100"
currency="EURO"/>
</account>
{
name: "Mega Corp Limited",
address : {
line1: "The Citadel",
city: "London",
postcode: "SW1"
},
balance: {
amount: 100,
currency: "EURO"
}
}
Which you have to convert to JSON

@spoole167
JsonObject jo=new JsonObject();
for(int i=0;i<l.getLength();i++) {
Node n= l.item(i);
switch( n.getNodeName() ) {
case "address" : jo.add(parseAddress(n)); break;
case "name" : jo.add(parseName(n)); break;
case "balance" : jo.add(parseBalance(n)); break;
}
}
You write some code

@spoole167
<account>
<name>
Mega Corp Limited
</name>
<address>
The Citadel
London
SW1
</address>
<overdraft limit=”500" />
</account>
And then the XML changes

@spoole167
JsonObject jo=new JsonObject();
for(int i=0;i<l.getLength();i++) {
Node n= l.item(i);
switch( n.getNodeName() ) {
case "address" : jo.add(parseAddress(n)); break;
case "name" : jo.add(parseName(n)); break;
case "balance" : jo.add(parseBalance(n)); break;
case ”overdraft": jo.add(parseOverdraft(n)); break;
}
}
So you have to change your code

@spoole167
This happens a lot<account>
<name>
Mega Corp Limited
</name>
<address>
The Citadel
London
SW1
</address>
<overdraft limit=”500" />
<credit>Low</credit>
</account>

@spoole167
String handlerName = handlers.getProperty(n.getNodeName().toLowerCase());
try {
Class c = Class.forName(handlerName);
IHandler handler = (IHandler) c.newInstance();
jo.add(handler.convert(handler));
} catch (Exception e) {
String errorInfo = "could not create class for handler" + n.getNodeName() + " class=" + handlerName;
throw new IOException(errorInfo, e);
}
}
private static Properties handlers = new
Properties(file,System.getProperties());
You change your code
address=com.foo.standard.AddressHandler
balance=com.foo.standard.BalanceHandler
name=com.foo.standard.NameHandler

@spoole167
-Dtesthandler=com.foo.standard.CreditHandler
Now you can easily add
Easy to update and test

@spoole167
And when things go wrong you get a nice error message
java.io.IOException: could not create class for handler credit
class=null
String errorInfo = "could not create class for handler" + n.getNodeName() +
"class=" + handlerName;
Missing handler in the properties file

@spoole167
And when things go wrong you get a nice error message
java.io.IOException: could not create class for handler credit
class=com.foo.handler.CreditHandler
Missing class on the classpath

@spoole167
What happens with this data?
<account>
<name>
Mega Corp Limited
</name>
<address>
The Citadel
London
SW1
</address>
<java.ext.dirs/>
</account>

@spoole167
java.io.IOException: could not create class for handler java.ext.dirs class
=/Users/spoole/Library/Java/Extensions:
/Library/Java/JavaVirtualMachines/jdk1.8.0_102.jdk/Contents/Home/jre/lib/ext:
/Library/Java/Extensions:/Network/Library/Java/Extensions:
/System/Library/Java/Extensions:
/usr/lib/java

82
Stack traces and error messages really help
More help I’m on the right track
More component info

@spoole167
Google search: intitle:Error Page pageWrapper.jsp?

@spoole167
java.lang.NullPointerException at com.stoneware.server.auth.OpenIDProviders.getProviderFromUrl(qx:91) at
org.apache.jsp.openid.openIDClaim_jsp._jspService(openIDClaim_jsp.java:248) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at
javax.servlet.http.HttpServlet.service(HttpServlet.java:790) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:438) at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:396) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:340) at
org.eclipse.jetty.jsp.JettyJspServlet.service(JettyJspServlet.java:107) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) at
org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:812) at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1669) at com.stoneware.filter.VersionCheckFilter.doFilter(wtb:391) at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) at com.stoneware.filter.SecurityFilter.doFilter(sed:802) at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) at com.stoneware.relay.b.A.doFilter(tlc:1671) at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) at com.stoneware.filter.SessionIDFilter.doFilter(bvb:1475) at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) at com.stoneware.relay.managers.f.doFilter(or:500) at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) at
org.eclipse.jetty.websocket.server.WebSocketUpgradeFilter.doFilter(WebSocketUpgradeFilter.java:224) at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:542) at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223) at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127) at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061) at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215) at
org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:52) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97) at
org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:332) at org.eclipse.jetty.servlets.gzip.GzipHandler.handle(GzipHandler.java:479)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97) at
org.eclipse.jetty.server.handler.RequestLogHandler.handle(RequestLogHandler.java:95) at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97) at
com.codahale.metrics.jetty9.InstrumentedHandler.handle(InstrumentedHandler.java:190) at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97) at org.eclipse.jetty.server.Server.handle(Server.java:499) at
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:311) at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257) at
org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544) at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635) at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555) at java.lang.Thread.run(Unknown Source)
Error traces can be used to identify what you’re running –
down to working out the version number…

85
Log / alert unexpected behavior
✓ Build in an expectation of what the client will be doing with
the data.
✓ All log entries must be useful – generic errors don’t help.
✓ Be careful about the amount of extra info in a log –
remember the bad guys may gain access to them too
Following good API design doesn’t mean you have to be too helpful.
Errors

@spoole167
#3 Error paths are as critical as normal flows
#4 Report only enough information to
identify the situation
• In general we’re poor at
dealing with errors in our
code.
• Developers focus on the
positive side.
• With consequential lack of
testing for error paths and
checking correct behavior
Errors

@spoole167
Security Features
Authentication, access control, confidentiality, cryptography, privilege management.

@spoole167
Can you rely on having a secure encrypted connection?
Browser Exploit Against
SSL/TLS (BEAST)
Compression
Ratio Info-leak
Made Easy
(CRIME)
Browser Reconnaissance and
Exfiltration via Adaptive
Compression of Hypertext
(BREACH)
Padding Oracle On Downgraded
Legacy Encryption (POODLE)

@spoole167
All data to and from the API is public
Even if you have a secure connection to the client
Man in the middle Reverse
engineered
client or app
Malware / xss
In the browser

90
Read the logs

@spoole167
Phew.
• So many things ways your
application can be
vulnerable.
• Security is not something
you add after. It’s always a
part of your design thinking.

@spoole167
Security Features
“I don’t need any security as the
system is local…”
“I’ll add security later”
“I’m not sure what security means”

@spoole167
Security Features
Many vulnerabilities come from poor authentication and access control
methods but ‘Security’ is a wider topic.
Confidentiality : Managing the data in your care
Cryptography : methods to ensure information is kept private
Privilege management: Ensuring actors are who they say they are

@spoole167
“I don’t need any security as the system is local…”
Security Features
Browser Server
Docker
Daemon
Remote
repositories
Local
repositories
WS
Cmd line
http
Adopt Server
http

@spoole167
Security Features
Browser Server
Docker
Daemon
Remote
repositories
Local
repositories
WS
Cmd line
http
Adopt Server
http
The browser is vulnerable to Cross Site Scripting attacks. So a remote attacker could get on to your system

@spoole167
Security Features
Browser Server
Docker
Daemon
Remote
repositories
Local
repositories
WS
Cmd line
http
Adopt Server
http
Since my tool uses an API that is unconstrained (ie the command line). The attacker could do anything
And the tool is downloading and running code from the web – another attack point

@spoole167
Security Features
Browser Server
Docker
Daemon
Remote
repositories
Local
repositories
WS
Cmd line
http
Adopt Server
http
The docker instance may have access to a secure repository. Without security my tool is enabling an easy bypass of
any access controls. The contents of the server are now available for a hacker to explore or use.

@spoole167
Security Features
Browser Server
Docker
Daemon
Remote
repositories
Local
repositories
WS
Cmd line
http
Adopt Server
http
So actually my tool needs really good security features.

@spoole167
Security Features
A few examples of vulnerable designs

@spoole167
Security Features
Trusting the end user not to tamper with the data
Cookie[] cookies =
request.getCookies();
for (int i =0; i< cookies.length; i++) {
Cookie c = cookies[i];
if (c.getName().equals("role")) {
userRole = c.getValue();
}
}

@spoole167
Security Features
Cookie[] cookies =
}
}
Does encryption solve this?

@spoole167
Security Features
Cookie[] cookies =
}
}
No!
XSS attacks often replace encrypted
cookies etc with ones from another
session that has the required
privileges.
You must have additional privilege
management processes in play

@spoole167
Security Features
Having endpoints that allows the
client to read the config
get: ”/api/v1/config/<key_name>”.
Returns json :
{ “key”: key_name , “value” : value }
public String getConfigValue(String key) {
return config.getProperty(key);
}
..
Poor confidentiality management

@spoole167
Security Features
My code has a endpoint that allows the
client to read the config
get: ”/api/v1/config/<key_name>”.
Returns json :
{ “key”: key_name , “value” : value }
public String getConfigValue(String key) {
return config.getProperty(key);
}
..
Poor confidentiality management
Since the config was backed by
System.getProperties all system
properties are exposed..

@spoole167
<servlet-mapping>
<servlet-name>PingPage</servlet-name>
<url-pattern>/status</url-pattern>
</servlet-mapping>
I found this
So I called it

@spoole167

@spoole167
Another Google search:
inurl:”8080/jmx-console”
This dork will list all unauthenticated jboss servers
with jmx-console access.

@spoole167
if (f.exists()) {
FileReader fr;
try {
p.load(fr);
fr.close();
}
return p;
}
Security Features
Unsophisticated credentials management
-Ddocker.user=foo -Ddocker.password=bar.
Storing information
In text files. Easily
readable.
Easily changed
on the command line.
(turns up in the logs)

@spoole167
Yet another Google search:
filetype:password jmxremote
#
# Following are two commented-out entries. The
"measureRole" role has
# password "QED". The "controlRole" role has password
"R&D".
#
monitorRole C0gnitive!
controlRole C0gnitive!

@spoole167
Security Features
That end up in your git repo…
Q: Can you easily remove password data from your
repo once committed?

@spoole167
Security Features
That end up in your git repo…
A: these people seem to think so..

@spoole167
TrustManager[] trustAllCerts = new TrustManager[]{
new X509TrustManager() {
public X509Certificate[] getAcceptedIssuers() {
return null;
}
public void checkClientTrusted(
X509Certificate[] certs, String authType) {
}
public void checkServerTrusted(
X509Certificate[] certs, String authType) {
}
public boolean isClientTrusted( X509Certificate[] cert) {
return true;
}
public boolean isServerTrusted( X509Certificate[] cert) {
return true;
}
}}
Security Features
Deliberate weakening of security
protocols

@spoole167
Github search “implements TrustManager”

@spoole167We’ve found 72,609 code results
AlwaysValidTrustManager
TrustAllServersWrappingTrustManager
A very friendly, accepting trust
manager factory. Allows anything
through. all kind of certificates are
accepted and trusted.
A very trusting trust manager that
accepts anything
// Install the all-trusting trust
manager
OverTrustingTrustProvider
AllTrustingSecurityManagerPlugin.java
AcceptingTrustManagerFactory.java
AllTrustingCertHttpRequester.java
Security Features

@spoole167We’ve found 72,609 code results
AlwaysValidTrustManager
TrustAllServersWrappingTrustManager
A very friendly, accepting trust
manager factory. Allows anything
through. all kind of certificates are
accepted and trusted.
A very trusting trust manager that
accepts anything
// Install the all-trusting trust
manager
OverTrustingTrustProvider
AllTrustingSecurityManagerPlugin.java
AcceptingTrustManagerFactory.java
AllTrustingCertHttpRequester.java
Security Features
How many are in your
dependencies?

@spoole167
Security Features
Defaulting to full access or running too much under privilege
method() {
AccessController.doPrivileged( new PrivilegedAction())
{
public Object run() {
// my app goes here
}
};
}

@spoole167
#5 Access controls as near to business logic as possible
#6 Keep credentials encrypted, safe and out of memory
#7 Fail safely
#8 Know your responsibilities for others
• For many the word ‘security’
is content free. Its all
someone elses problem.
• It’s not – every system needs
to understand its security
posture.
• Where do you check access
control?
• Where and do you store
credentials?
• Will you default to a safe
mode or an ‘all access pass
mode’ ?
• BTW - How much code gets
run before you say no?
Security Features

@spoole167
This is straightforward
If your system is too complex
to understand
Or just poorly written. It’s
more likely to have edge cases,
weak spots etc
So more open to being
attacked
Code Quality
#9 Keep it simple
# 10 Have a full test suite
# 11 test for failing conditions:
even security related
Poor code quality leading to unpredictable behaviour and
opportunities to stress the system in unexpected ways

@spoole167
Write code defensively
https://blog.jetbrains.com/idea/2017/09/code-smells-too-many-problems/
Often the path through the
code is decided only by the
data provided
Bad guys look for
unexpected paths by fuzzing
your data
Don’t have unexpected
states or code paths..

@spoole167
Encapsulation
Insufficient encapsulation of critical data or functionality
Errors that allow functionality or data
to cross trust boundaries
Escalation of data access privileges
Insecure import of untrusted code
Exposure of information through
unprotected resources
#12 use immutable state where at all possible
#13 Do not give away extraneous data
#14 Only hold the least amount of critical data – and throw it away as soon as possible
#15 Reduce functionality to just the usecases needed - No nice-to-haves !

@spoole167
#16 control of state never
leaves your system
• Client can send you requests
to change state but it must
never own the state.
Time and State
Unexpected interactions between threads, processes, time,
and information (shared state)
people put state into a cookie and
assume it cant be modified if
encrypted..
What happens if someone sends you
an encrypted state object from another
session…
Did you have a flag in the state that
said the user had higher privileges.?

@spoole167
• All the parts of your development
process
• The tools you use
• Your dependencies
• The operating system
• The build machines.
• The code repository
• All these can be vulnerable to
attack.
Environment

@spoole167
Authentication, access control, confidentiality,
cryptography, privilege management.
Unexpected interactions between
threads, processes, time, and information
(shared state)
Errors related to error handling
Problems caused by metacharacters,
alternate encodings and numeric
representations. General security problems
result from trusting input.
Using an API in a manner contrary to its
intended use
Insufficient encapsulation of critical data or
functionality
Everything that is outside of the source
code but is still critical to the security of the
application
Time and State
Poor code quality leading to unpredictable
behaviour and opportunities to stress the
system in unexpected ways.
Errors
API abuse
Code Quality
Security Features
Encapsulation
Environment

@spoole167
Summary
1. Hackers use sophisticated tooling to attack you
2. These tools look for known vulnerabilities and common design errors.
3. Everyone makes mistakes (some of which we don’t know about yet)
4. Relying on one single form of defense is the ultimate foolishness
5. Right now its about defense In depth
6. Make sure you have alarm systems: Invest in detection, invest in the
strongest encryption, invest in security testing, design for defense
7. Take a long hard look at your design choices – easy for developers = easy
for hackers
8. Turn your suspicion detector way up when using other peoples code

There are bad guys out there and your
application is at risk
Don’t make it worse by ignoring the problem
https://www.flickr.com/photos/koolmann/
@spoole167

Seven perilous pitfalls to avoid with Java | DevNation Tech Talk

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Seven perilous pitfalls to avoid with Java | DevNation Tech Talk

Similar to Seven perilous pitfalls to avoid with Java | DevNation Tech Talk (20)

More from Red Hat Developers

More from Red Hat Developers (20)

Recently uploaded

Recently uploaded (20)

Seven perilous pitfalls to avoid with Java | DevNation Tech Talk