This talk is about permitted activities,

we're talking about users now,

that can cause problems.

A number of years ago when I was working for a large huge defense contractor,

I came to work one morning and found an email in my inbox from a person I didn't know.

It turns out that she was an administrative person located in Florida,

I was in Colorado and she accidentally sent

some trivial e-mail to the distribution list for the whole company.

At the time, this is about 80,000 people.

Soon, someone replied, also to the entire company,

that he was irritated,

that he was getting unimportant e-mails about

subjects he didn't care about from people he didn't know.

I guess he'd never got an email from HR.

But, his reply was to the whole company.

This continued one by one.

People who think differently than I do hit Reply All and blasted

either the original email or someone who had hit reply all to it.

In about an hour or so, email wasn't happening.

I suppose in addition to choked servers,

IT was taking them down to clear out their cues and

also disable access to the whole company distribution list.

This didn't help the Reply All problem but

it did prevent future occurrences of the problem.

So the email system ground to a halt.

Effectively, it distributed denial of service attack monitored

by people who don't think like I do.

This is a case of a permitted behavior,

sent through a distribution list,

causing a serious problem.

More in line with security,

let's look at the use of fingerprints for identification. Okay. That works.

We can create an authentication system where you can't

lose the password and since people have unique fingerprints,

no one else will have your fingerprint.

The problem though is that you only have 10 fingerprints and once one is compromised,

you're done with that one forever.

This wouldn't be so much of a problem if you could keep your fingerprints to yourself.

However, the FBI among other

organization counts on bad people leaving their fingerprints on smooth surfaces.

Unless you wear gloves all the time,

you'll do the same.

In December 2014, a German security researcher reported on how he used

publicly available photographs to reproduce

the fingerprints of the German defense minister Ursula von der Leyen and last year,

I was on a masters committee of a student who used an analysis of

side channel activity in a fingerprint matching algorithm to create a fingerprint,

which could be authenticated.

Again a desirable behavior of fingerprint authentication,

but which can be exploited.

The final example comes from our own field of software engineering, modularity.

This is the idea that you have

one and only one place in your code where you do a particular thing.

You have only one Julian date conversion routine for example,

so that if something needs to be modified,

it only needs to be modified in one place and the problem is fixed.

But this is a double-edged sword.

If the software is broken in that one place,

then it's broken everywhere.

The open SSL bug commonly known as Heartbleed is a good example.

Open source code, which many many people in

organizations use to secure the transport layer.

Modular code is good unless it isn't.

The desirable behavior of fix it once can be a bad thing.

Now actually, I'm not going to recommend fragmenting

your code so that if one free form text entry control has a security bug,

a second one you wrote and using the same software might not.

The real idea is to think about what you want your software to do.

How it can be used against you or the user.

And of course, this means thorough testing.

A particularly difficult aspect of this problem

is that we can't write a checklist to help you solve it.

Or maybe the checklist would have two items in it.

One, think hard about someone who could exploit the intended behavior.

And two, think harder.

This is a problem where you have

to think outside the box because the attackers certainly will.

In this regard, having a second person other

than the designer examine the system is useful.

The designer will tend to think in

the same patterns and may not see a problem with what's been designed.

A third party however may bring to the table a different

perspective which will reveal weaknesses in the system.

As an exercise, let's look at several requirements you

might encounter and decide if there is a security threat to any of them.

And if so, what is the threat and how it might be mitigated.

First requirement,

be able to drag and drop a text file or any formatted file to be processed by a program.

The text file constitutes free form input.

Just because you can't see the data that's being transferred,

doesn't mean it's safe.

The text must be handled with the same rigor as any free form user input.

Even if the text file is generated by another program,

can a malicious user substitute

a specially crafted file for the one that

should have been generated by that other application.

Further, what's actually dragged and dropped is not

the file itself but the file name and the path to it.

What if this was specially crafted.

Can it be parsed incorrectly and caused damage.

Second, network card interface.

If you are fortunate enough to be writing code this close to the network,

then you should consider that the formatted packets you

receive may be formatted incorrectly and for a reason.

Make sure your processing can handle

absolutely random inputs as well as cleverly crafted ones.

Three, update based on a page scrape.

I worked on a project whose job was to process

the data from another website's pages. What's the threat here.

The page of the other site doesn't have to correspond to any rules.

Since it's hypertext, the characters

behind what appears to be on the page can be a threat.

The bottom line here,

you're not guaranteed that the characters you get aren't going to be a problem.

Fourth, file compression and decompression.

Requirements to handle file compression and decompression are interesting.

The compression is normally not

a problem since the data represent nothing more than the data itself.

There is no implied format and one bit doesn't mean anything more than another.

The idea is simply to reduce the size of the data.

That's not the same as processing it.

On the other hand, decompression can be perilous.

Decompression depends on the file being in the correct format.

Anomalous situations and threats to security can happen when

specially crafted files are being decompressed.

Five, storing a blob in the database.

A blob is a binary large object.

It can be anything, an image,

a file, a document.

Like files which represent input for compression,

the blob isn't assumed to be in any format.

It has a beginning, an end and a lot of bits in between.

There's little threat in storing a blob in the database.

Processing it however is a different matter.

A different type of threat situation that arises from

desired behavior is when the behavior is repeated.

You'd like your bank to transfer $150 to pay off a creditor.

But, what if the bank does this six times?

That's not what you intended.

It's not a good thing.

Many interactions with databases involve transactions.

A sequel insert, update or delete statement is a simple transaction.

Other systems operate with transaction processing as well.

The key here is the idempotent transaction.

A transaction that has the same effect regardless

of how many times it is done, is idempotent.

A sequel delete statement,

for example, can be idempotent.

If you execute the statement 20 times,

the item you deleted does not become more deleted.

It was deleted once and subsequent deletes have no effect.

Of course, the behavior of the delete statement depends on how you write it.

Compare these statements.

Delete from user where user ID is equal to one, two, three,four five

and delete from user where user ID equals select max user ID from user.

The first statement is idempotent.

It has the same effect regardless of how many times it is executed.

The second statement will delete the user with the highest ID number in the user table.

If executed five times,

it will delete up to five users.

If this were a database course,

we could discuss all sorts of clever ways to make database transactions idempotent.

For now though, you should simply know that there are ways to do so.

In this talk, we've discussed normal software behaviors,

which can become a threat to security.

When constructing systems especially complex ones,

it's necessary to examine what the system does to

see how normal behavior can be destructive.

And often having the person who didn't design

the system perform this function is very useful.

Permitted Activities that Can Cause Problems

Software Design as an Element of the Software Development Lifecycle

Conheça os instrutores