>> Tune into this week's Xamarin Show where
I have my good friend Kerry, and all the way from Germany.
Kerry, what are you talking about?
>> I'm talking about App Security,
how to get your app secure.
>> I love it.
It's super important for mobile applications nowadays.
So, make sure you tune in.
>> Welcome back everyone to the Xamarin Show.
I'm your host James Montemagno and today,
we're going to be talking about mobile app security with
my good friend all the way in from Frankfurt,
Germany, Kerry. How's it going, Kerry?
>> Good. How are you?
>> I'm really good. I woke up super early this
morning because we got a slot
really early in here in Channel 9,
and who doesn't want to wake up
at 6:00 AM and talk about security?
>> I got up at 3:00.
>> Exactly. So Kerry wins all of a sudden.
So Kerry, first, you're
in Microsoft MVP so something is going on.
Can you tell everyone a little bit, who you are,
what you're here to talk about
and a little bit about your background?
>> All right. My name is Kerry Lothrop.
I work at Zuka in Frankfurt,
Germany and we do projects for customers.
We don't have our own products.
So increasingly, in these projects,
security is a big factor.
The type of projects we're doing,
they are not just your App,
Marketing Apps something like that.
Usually, there is something connected
like a Bluetooth connection, a real device.
People pay a lot for the products,
and they get an app where they have
certain expectations about the quality
of that app and that,
of course, involves or includes security.
So, that's what I focus on.
>> Got it. The reason then I've seen you a lot
of time speaking in Evolve.
I've read your blog posts, and I
think when people think security often,
they're like, "Oh, I've encrypted
a string or I have encrypted my database."
But that's not all we're talking about today, correct?
We're talking about something different.
>> I was going to focus on network security
because I see a lot of people
are doing things wrong there.
So, that's what I was going to focus on today.
>> Well, when I think of network security,
I've always heard the joke
or maybe it's not a joke that HTTPS, right?
I just put everything through HTTPS, is that good enough?
Is that good, is that bad?
Is that the silver bullet of security?
>> That's a good start.
So, HTTPS is, well, on mobile,
if you want to do some sort of connection
it should be HTTP because
usually mobile phone can be
inside a network that will not allow anything else.
>> Yeah.
>> You're in the coffeehouse and they won't allow
any direct connection to
Sequel Service something like that.
>> Of course, yeah.
>> So, with HTTP, but
if you want to be secured, it's HTTPS.
>> Got it.
>> And you know it HTTPS from
the web world so you type in the URL up
there and as a user.
>> Like a little green secure it
makes you feel warm and fuzzy inside.
>> Green, yellow and makes you feel good.
>> Yeah.
>> And the user or like
my grandmother can see this is secure.
This is my bank I'm talking to,
I can enter my credentials
and with apps you don't have that.
You can put a lock icon
in your app but it doesn't really do anything.
>> Yeah.
>> So, people are entrusting you as the developer
to do everything in
a secure way and to
make sure your data is handled correctly.
>> Yeah, and I think it's all
focused on network security.
I've always think of, you're not embedding
your strings into my application and
securing things into like there's
the key store and the key chain in iOS and Android.
Those are other things that you should be
doing to secure your data in your app.
>> Right.
>> When I think of network, it's like how is the data
coming and going to the application
itself and making sure that someone is
not swooping in there, in those coffee shops.
I do some work sometimes in the coffee shop.
>> I heard, yeah.
>> And it happens.
You're just there and at
the same time everyone's on the public Wi-Fi.
I think more nowadays,
this is more important is we're always so connected.
Not just with our laptops, with our phones.
I travel half the year I've connected to
Boingo Internet a thousand times at this point.
>> Right.
>> And the security model on that,
it's not the same when I'm on Microsoft Corp Net, right?
I'm on a Corp Net, things work,
things don't work because IT
is locking things down but you're right.
I think more and more as we see
these large companies go
through security issues and hardware,
we should be pretty cognizant of this.
>> Right.
>> Yeah.
>> And when you say you're in the coffeehouse
Wi-Fi but you don't actually know
that that's the coffeehouse Wi-Fi actually.
>> True.
>> It could be some other Wi-Fi
because not only does your phone scan.
Are there any Wi-Fis near that I know?
Like in this coffeehouse or this airport nearby,
they also broadcast that information also.
They like shout out. I know this Wi-Fi,
is it anywhere close?
>> Yeah.
>> And then as an attacker you just have to respond "Yes,
I'm that Wi-Fi" and your phone will connect to it
automatically without you realizing that.
And the good news is if you do
your homework regarding security right then,
it doesn't matter if the connection is
bad or if there's someone in
the middle because it will either
work and be secure or will not work at all.
>> Yeah, and that makes sense.
So, what we're really seeing in
that scenario then is this bring your own device.
You're in this corporate environment,
your employees are going out with their devices.
No matter where they go,
whatever what Wi-Fi they connect to,
what you're going to show is going
to show us how to make us secure.
>> Right. Yeah.
>> Let's do it. Let's jump in. I'm ready.
Talk about your setup here a little bit.
You got some phones and some adapters here.
Let's walk through what you got.
>> So, I've got a Mac here.
I'm using Visual Studio from Mac,
the update from yesterday.
>> Perfect.
>> So, let's hope this work.
I've got a phone connected.
So, it's a real device you see the icons are
jiggling and I've got a windows VM here.
>> Yeah.
>> And I'm running a tool called Fiddler from Telerik,
and I've set up my phone so that the traffic from
the phone runs through a proxy server and I
entered the IP address of the Windows machine.
>> Okay.
>> It has its own IP address
because I have a network card here.
Another Wi-Fi USB card
that's connected to the same Wi-Fi,
and the traffic from the phone is
running through the proxy server here.
>> Okay.
>> And so I can basically see what the phone is doing.
>> It does make sense because
even the beginning of trying to
secure your apps is how do you even do it?
You're like I need this network and this and this,
and this is pretty interesting
because everything is on the same network.
But you're essentially going to be piping
your data through
your Windows Virtual Machine
to see every little bit of
traffic when you see some iTunes stuff happening.
I guess anything is communicating.
>> Yeah this is the phone
communicating through its home base.
>> Very cool.
>> All right. Yeah. So, this would not be how you,
well, usually people don't set
their proxies server to this.
But this is what somebody in between
you and the server you're trying to
reach would be able to see.
>> Got it.
>> If you were a man in the middle.
>> So we can think of this
Fiddler session as the man in the middle,
someone that may intercept.
>> Right.
>> And can see all of your traffic.
>> Right.
>> Okay.
>> And we'll see what that person would be able to see.
>> Awesome, cool.
>> So what I've done here on this slide I've wrote
a not so pretty Xamarin App
and it has one button and if you tap
that button this code behind, code gets called.
And what I had to do here is I set up
the Fiddler as a proxy server itself.
It's a little Xamarin detail,
the Xamarin has a reimplementation of the HTTP clients.
And if you use the default one,
it's going to be the Monoweb implementation,
the real.net implementation and
it ignores the proxy settings on my phone.
>> Okay.
>> So for this test I just entered that here.
>> So if you're using CF networking or the other stacks.
>> Right.
>> You might go through but
since it's our implementation,
it makes sense that you're using the HTTP client
handler site.
>> Right. But then other features
of the HTTP client might not work.
>> Yeah.
>> So, this is the one I picked for the demo.
>> Make sense.
>> And I have a blog post where there's a list of
the possible HTTP client handlers
and you can see which ones have which features.
>> That's good.
>> Yeah.
>> And someone asking me about
that literally on Twitter yesterday.
Someone send that up.
>> Yeah.
>> How do you use the default? So this
is probably most Devs are used to.
>> Right.
>> So what I want to do here is just do
a plain get HTTP call on Microsoft.com.
And if it works,
we'll show pop up "Success" and
if it doesn't we should see an error message right here.
>> Okay, cool.
>> So, I'm just going to run that on the phone.
>> So this to me is just a standard networking calls.
I've used HTTP client a thousand times.
>> Right.
>> I've made very similar calls on this are just
getting and this get is anything essentially the page.
But a lot of people are probably used
to getting string, getting stream.
Is that accurate, is that the scene
here essentially is just get a sync?
>> Right.
>> That's what you're getting.
>> That the normal.
>> Perfect.
>> HTTP get. All right.
So I'm going to tap "Make call" here.
And what does it do?
>> Success.
>> Success. So, what we see here on the Fiddler's side,
we see there was a call to Microsoft.com
and with the inspectors here,
we can look at what was inside the headers.
And this is Rod calling to
Microsoft.com and this is the response.
It will probably be some redirection to a
secure a site maybe or
maybe it's just the whole website in one line.
>> Nice. Yeah.
>> But I'm getting results.
The app thinks we got results from
the server but actually someone
in the middle was able to read that.
>> Yeah. So literally,
right there we could see the entire request.
>> Right.
>> Fully and the response fully, too.
I think that's the important part is that.
>> Right.
>> Everything is plain text.
>> Right.
>> Is that because of HTTP?
>> That's because it is HTTP.
>> Okay. Got it.
>> So what we could do. You know Microsoft
is available through HTTPS, too.
>> Yeah.
>> So, I'll just try that.
Add an s here and I'll run that again.
>> Yes, so essentially,
if you own the back-end,
kind of out of the box, let's
say you're hosting on Azure.
>> Right.
>> Azure websites, you're going to get
HTTPS out of the box.
>> Right.
>> If you set that up. Then, I know also,
if you're using a custom domain though,
you're going to use some cert like Cloudflare
or other cert kind of server, right?
You have to set that backend up somehow.
>> Right.
>> So, Microsoft obviously has done that,
which is why we have HTTPS.
But you can't just add an HTTPS
and have it magically work.
>> Right, your server has to support it.
But you don't actually have to
buy a certificate. We'll get to that later.
>> Okay, cool.
>> So, let's check what it looks like here.
So I'll tap "Make call",
and we should be seeing a response.
So, okay, it gives an error message, certificate unknown.
This is something else. Okay, this was expected.
So, we see here in Fiddler
is it's trying to connect to www.microsoft.com,
and what happens,
I make the request to the debugging proxy,
the debugging proxy makes a requests to microsoft.com.
So, and it gets a response,
decodes that response and encodes it again for my client.
>> Okay.
>> So the client gets
a different certificate for
that than it would from the original server.
So, I can tell that apart,
and the user agent can tell that apart,
so it's saying here, the certificate doesn't match,
I don't trust www.microsoft.com.
If I were to call this in a browser,
I would see it's issued by
root authority called, DO_NOT_TRUST FiddlerRoot.
>> Okay, got it.
>> This is what's happening here.
So, but even this I could show you how to intercept this,
this is a neat trick.
You can call this URL help here,
it's called ipv4.Fiddler: and
then the port number that Fiddler is using on.
Then you see some information about
Fiddler here and it says,
you can download the Fiddler certificate,
and it will give us a warning messages and I can
install the Fiddler Root on my phone.
It says here more details.
So this is s the name
of certificate, DO_NOT_TRUST FiddlerRoot.
It is basically issued by my computer here and
that's by the windows machine,
and that's why the other computer doesn't trust it.
So I can just tap install here,
then have to confirm that I want to install.
Then I have to go done,
then I have to go back to the settings.
This is really interesting,
about then down here certificate trust settings.
There I see the certificate and
I have to explicitly say I want to trust this,
then I get asked, do you will you want
to trust this? This is really bad.
When I do that,
then my- all this is not going to work.
But my operating system will
then trust Fiddler for requests,
so I just realized this will not work because it's
the HTB client from Xamarin and it does not value
those- let's see if it works, I'll just give it a try.
>> So what essentially has happened here is
the Microsoft server is not
trusting their certificate that Fiddler is passing,
is that's what's happening in this scenario of debugging?
>> So what happens that the client gets
a response and it has to somehow- HTTPS is nice.
It means I've got
a secure connection but you
don't know who you're talking to.
>> Got it.
>> So the way it works is I have a list
of Root certificate authorities
that my operating system knows.
iOS has that list, Mac OS,
Windows has a list and it's
these- a list of 200 authorities.
>> Got it.
>> You can look at that list here.
System Roots and it's
a big list of all the companies that my computer trusts.
>> Got it.
>> What I did was I added Fiddler to this list.
>> Got it.
>> On the phone.
>> Got it.
>> So now the phone should be able to trust Fiddler.
Let's see if it does work.
Not really sure.
I don't know why it's so delayed.
Success. Okay, it did work.
So it's using the Root certificate list on
my Operating System, and what I
can do here is I can look at all the contents,
so it's a HTTPS call.
>> But you can see everything?
>> But I can see everything, right.
>> Is that because of the trust between them
or- but I always thought you know
HTTPS everything's encrypted everything's magical, right?
>> Right. That's because I installed
the certificates of the man in the middle into my phone.
So this is also not a typical attack vector,
you would have to have physical access to
the phone to do that.
But what it does
show you is the only HTTPS stuff
is built around browsers,
and browsers rely on this Root certificate list here,
to authenticate any type of website you might encounter.
>> Got it.
>> When working in a mobile app,
that is not really necessary because you don't have to
just trust any server
you know I'm going to talk to my server,
and I want to trust this server,
not just any server that my operating system trusts.
>> Got it, this makes sense.
That's what's essentially happened here,
is because we installed this server, we're like,
hey everything's great and kind of look and add this cert
in and now anyone
could really use that cert at this point,
but I know that I'm going to be talking to
my Azure website or I'm going to talk
to my backend that's hosted somewhere.
>> Right.
>> So we should be able to- I mean make that handshake,
right? Is that the idea?
>> Right, that's the idea.
>> Because we can trust each other.
So right now we're trusting everybody?
>> This list, you sometimes see it actually modified.
There are manufacturers of
PCs that install their Root certificates on their
or there are companies that instal
the company root certificates on
each employee's device so they can listen to the traffic.
>> Got it.
>> Yes, kind of not a good idea to trust this list.
>> Yes, especially on a phone where you know,
and your own app where you know exactly what's going on.
So can we secure this app
then and make it all fancy schmancy?
>> So the next step would be,
I could say this the code up here,
I want to add some code
to do the verification of the certificate myself.
>> Okay.
>> What I'm doing here is I specify this function here.
And what it does it gets all the information,
the certificate, and the chain, and any errors.
It looks at the public key and it
just compares that public key
to some magic string up here.
This is magic string is
the actual public key of the web server I'm using here.
>> That's okay to put it in the
app because it's the public?
>> Right. This is the public key,
it is- the server will tell you if you ask it.
>> Got it.
>> If somebody manipulates that,
that only affects his own app.
>> Got it.
>> Not all the other installations.
>> Okay.
>> So what I'm going to do here,
this is now active and I'm going to
debug this again or run this again. Okay.
>> So, this is a really easy check essentially.
So, this comes in
and it's happening every single callback essentially,
in the handler is going to get this callback.
>> Right. Every website you access is going to check,
is that actually, this exact server,
does it have this public key?
Because, if it has this public key,
that means it has the corresponding private key.
Because, you couldn't generate a public key-.
>> Without it.
>> Or the corresponding private key for that public.
>> Got it. Cool.
>> So, now we've got the app running again,
hit "Make Call" and see what happens.
Okay. I get an error message again.
So, even though this thing trust Fiddler.
It doesn't work because I don't want just any web server,
I want this specific web server.
>> Got it.
>> So, we can also see here that, this other line is,
I only want to trust a specific level of TLS, the latest.
All the prior versions have already been hacked,
and the web server will basically,
the client is written so,
it will work with older servers.
Why should it? Because, I know I'm calling
my own server and I know it is up to date,
and I only want to allow that.
You can also do it vice versa.
Why should the server trust a client that says,
''I only know SSL tool,
really from from 15 years back''.
>> Yeah.
>> When it knows, my client
understands tiller as one point two.
>> Yeah. So, we should use that.
Not only am I only going to,
if I get the requests, I'm going to check at that point.
Then also in the phone kind of double checking.
>> All right.
>> This is really important, cool.
>> So, this is called certificate pinning.
Or certificate pinning and version
pinning or actually this public key pinning,
I could do this at a greater scale,
or think through this a bit more.
I could check the certificate authority,
that it is issued by my company.
Maybe, if I want to rotate the certificates.
But, the certificate doesn't even
have to be trusted by the Operating System.
I could use a cell signing certificate
on the server side,
and then have it's public key inside my app.
And still, this would be much more secure than just
relying on the third route certificate authority list.
>> Got it.
>> Right.
>> So, now even if we run this,
it's going to be the same error message
essentially that pops out?
>> What they tell us one point two?
>> Yeah.
>> That's the same. This didn't matter any for this demo.
>> Got it, okay, nice.
So at this point then,
is the mobile app secure because of this,
at this point or what's the next steps?
>> This is much more secure.
So, there are other things you can do from the,
let's talk about the back end side maybe.
So, I said before
maybe you only want to trust this certain versions.
But sometimes, the big picture,
the app now knows exactly it's talking to my server.
>> Yeah.
>> And then, oftentimes we have people saying,
''I have this back end and I
want to make sure it is my app,
it's only my app that's talking to my back end."
>> Got it.
>> And, that is something that's very difficult.
So, what people start doing is,
they send along credentials,
or send the client certificates,
and they want to make sure there's
actually their own app, that's calling the back end.
>> Yeah.
>> But, that doesn't usually work.
Because, you have to embed that information that,
this is your app inside your app bundle.
>> Yeah.
>> Now, gets back to the storing.
>> I've seen that oftenly, like I'm going to
put the certificate inside of it,
I'm going to put all this information inside the app.
Then, what of your app,
someone busted open, at some point.
>> Yeah. So, then people tried to
hide it inside their app, encrypted,
or hide it in the last spites of
an image resource or something like that.
And, but at one point,
it gets passed to the API call.
Use this client certificate,
and so if you're dynamically instantiating the app,
you can look into that and
basically scrape the certificate,
and then, you can make those calls to the server.
So, basic what you should be doing is,
don't authenticate your app.
Think about authenticating the user.
>> Got it.
>> Like a website works,
you don't write a website,
that only works with Opera,
these versions of Opera.
And, you write a website,
you can access it freely, but,
if you want to do something special,
then you can, you log in and you authenticate the user.
Then you can also block one user.
You can remove his access but,
if you have the certificate out there on every app,
and it gets compromised then you can't pull it.
>> You can't pull and you can't expect everyone to
upgrade the application either,
because we all know that
people linger on the app updates.
So, now this application this codes,
and some of the public can hear,
you then we're updating it hitting the server,
where the private key was,
then you're going to be able to see everything.
Or, is it all going to be encrypted inside of Fiddler?
>> With this, I can't intercept it with Fiddler.
>> You can't intercept that.
>> I would have to look inside the app,
if maybe on a routed Android device,
I would be able to look inside the app,
and see what are the calls that are being made.
>> Got it.
>> But I can't intercept this anymore.
>> Perfect. So, it's kind of recap,
and you can correct me if I'm wrong here.
First obviously, moved HTTPS.
>> Right.
>> Then also, ensure that you're
doing your actual public key checks.
That your back end has a private key,
that it's all set up that way.
And also, at the same time enable
TLS one two support on both ends.
>> Only.
>> Only. That' it, because I do any other ones.
In fact, I've noticed over time,
a lot of the services I've called have,
required one dot two,
which is then we had a kind of
select the different implementations of HTTP client,
but all the Xamarin stuff now
uses 'tell us one', or 'two out of the box'.
>> Right.
>> It's all built in for you.
So, it's all there don't think you
have to go through any crazy other network code.
If you just use HTTP client, you're good. Cool.
>> All right.
>> Awesome. Anything else you wanted to
show off her cover?
>> That was about it.
>> Awesome. I love it because not
only did I actually learn how to use Fiddler,
and this huge crazy setup.
So now, I can actually start debugging,
and looking at all my applications.
But, you can see that it's actually not that much code.
It's all built in really,
and just changing a few URLs,
making sure your keys are in there,
and thinking about that I guess is important.
>> Right. What you can't do is just,
be that man in the middle.
Look at your own app, see what you can see and that is,
what somebody else could be seeing.
>> I like that, Awesome.
Well, Kerry, thank you so much for
coming on, and showing this all.
We'll put all your blogs, all the links,
and I think even to your evolve talk,
in the show now it's below.
Yeah. Thanks for making that trip out here.
>> Thank you.
>> Yeah. Well, until next time,
it's been another episode of the Xamarin Show.
Don't forget to subscribe.
You can hit that little button
down over there, up over there,
ding that bell to get notifications
right in your inbox each and every week.
Until next time, I'm
James Montemagno. Thanks for watching.
For more infomation >> Научи животните на Български - образователно за бебета и малки деца. Learn Animals in Bulgarian - Duration: 2:00. 
For more infomation >> Bem-vindos ao canal da ONG E-Pet - Duration: 1:59. 
For more infomation >> ما هي أعراض الجلوكوما ؟ - Duration: 0:24. 
For more infomation >> 🔴 [LIVE] PUBG MOBILE: Tryhard to ACE Rank (Rank Thách Đấu đang chờ) - Duration: 1:25:50. 
For more infomation >> What If Hellhounds Were Real? - Duration: 5:33. 
For more infomation >> The Women Who Work With Dead Bodies - Duration: 2:39. 
Không có nhận xét nào:
Đăng nhận xét