You will learn to extend your knowledge of making iOS apps so that they can securely interact with web services and receive push notifications. You'll learn how to store data securely on a device using Core Data. You’ll also learn to securely deploy apps to the App Store and beta users over-the-air. The format of the course is through a series of code tutorials. We will walk you through the creation of several apps that you can keep as a personal app toolbox. When you make your own apps after this course, you can bring in these capabilities as needed. When necessary we pop out of the code tutorials to talk about concepts at a higher level so that what you are programming makes sense. Upon completing this course, you will be able to: 1. Post Facebook, Twitter, Sina Weibo, Tencent Weibo messages to social media using single sign-on on behalf of a user. 2. Use OAuth 2.0 to securely authenticate to Instagram and retrieve photos on behalf of a user 3. JSON 4. Describe JSON’s syntax 5. Write well-formed JSON 6. Work with JSON data objects in Objective-C 7. Appropriately set the security settings for App Transport Security in iOS 9.0 8. Use http, https and https with perfect forward secrecy to fetch web resources 9. Obtain permissions to receive local push notifications 11. Write an app that can send and receive local push notifications 12. Obtain permissions to receive remote push notifications 13. Write an app that can receive remote push notifications 14. Authenticate using Apple’s cryptographic services such that the developer can use 3rd party infrastructure to send remote push notifications to their app. 15. Securely store data on the user’s device. 16. Authenticate using Apple’s cryptographic services such that they can deploy an app to the app store
Network Security Considerations
Loading...
來自 University of California, Irvine 的課程
Networking and Security in iOS Applications
227 個評分
University of California, Irvine
227 個評分
課程 2（共 6 門，Specialization iOS Development for Creative Entrepreneurs）
從本節課中
Using Secure Web APIs: an Instagram Case Study
Now it's time to consider what we are going to do if we want to work with web services that aren't deeply integrated into iOS. There are hundreds (thousands?!?!) of them. Most of them require authentication via the OAuth 2.0 protocol. In this week's lessons we will walk through an example of getting a photo from Instagram on behalf of a user. This week is also a code tutorial in preparation for your peer review assignment, but in the middle we need to step back from coding to cover some basics: How do we use a UIImageView? What is OAuth 2.0 anyway? What is JSON and how do we read it? What's the big deal about http vs https anyway?
與講師見面
Don PattersonAssociate Professor
Informatics and Computer Science
Sam KaufmanPartner at Gradient
[MUSIC]
Sam and I wanted to put together a little bit more information about network
security considerations for you.
To make sure you understand the complete picture of what's happening on
the network as we talk about transmitting information over HTTP, HTTPS, and
we talk about the ATS settings, the app transport security settings.
So at a high-level, keeping data secure requires an understanding and
commitment to security first.
And security doesn't just happen in one place.
We're just gonna be talking about security on the network, so network security.
But there are other kinds of security that are important too.
For example, data security, keeping data secure while it's on a device.
We'll be talking about that a little bit more when we talk about core data.
And then there's other things like physical security.
How do you make sure that if someone has an iOS device, it remains secure?
These are all different things that security researchers and
people that are concerned about security, think about.
But we're gonna focus just on one aspect of it in this lecture,
an aspect that we've been talking about a lot, which is network security.
In fact, a lot of this was brought to life
by Edward Snowden's release of top secret US information.
That sort of demonstrated, not sort of, it demonstrated that there were
a lot of entities that were interested in capturing information about people.
That people were creating and moving across the internet.
That upset a lot of people.
And so some of what we're talking about, ways in which computer
companies and individuals are responding in response to those revelations.
So if you think about the Internet abstractly, which most people do.
You should generally think about a smartphone, a device, a browser, a laptop,
accessing some web server, like a web site, like maybe CNN.com or Apple.com.
And you just generally think of the fact that when you make that request,
when you request data or when you send data.
It goes over the Internet, and the Internet is kind of this cloud.
And we know it gets there somehow, and
it's kinda like the telephone system, I guess.
And maybe it's kinda like television, I guess.
And the information goes through this cloud, ends up at the web server.
And then it kinda sends it back.
And there's a little bit of mystery about what's happening there.
But revealing what's happening in that mystery is important for
understanding why we're doing the security considerations that we are.
So, a less abstract Internet looks like this.
This morning I actually mapped out the path between my phone and a server at UCI.
And in the center is the output of that mapping.
And then this diagram shows a graphical representation of it.
And what you can see is that there are at least 16 different computers that
are involved in moving my data from my phone to the web server.
So, those 16 servers that are involved each get to touch my data,
and in some cases get to see it.
So when I send data, I create some data on my phone and I pass it, and
I wanna send it to the web server.
I pass it off to my Internet service provider and
since in this case I was working with a smartphone that was on a data network.
The first place that it went to was to a computer controlled by Verizon.
If you were on WiFi it would go probably to your internet service provider or
if you're in sort of an organization it would go to your organization's network
provider.
So like a Comcast or a Cox in the US.
That first step receives my data and
then pushes it to another computer that's a little bit closer to my destination.
And it works a little bit like the freeway system, where the first computers
that you connect with are low bandwidth and way out on the edges of the Internet.
And then as you get to the middle you get to these high bandwidth,
freeway kind of connections.
And then eventually your packet will go a long distance if it needs to,
perhaps across the country or around the world.
And, then it will get off an exit, if you will, and one of these smaller networks
will pick it up and move it down until eventually it gets to the remote computer.
So Verizon passes it off, 1, 2, 3, 4, 5,
6 different computers that are within the Verizon network.
And through a number of different computers all the way to the web server on
the other end.
And then when the web server responds with that data,
it comes back over a path that's similar.
It may not be exactly the same, but it's similar to what it came across.
So let's assume that it's the same coming back in this example.
So the first step from that server at UCI is a UCI router or computer along the way.
And then there are all these companies in the middle, and
these are the actual companies.
So the next company is a company called Scenic, I guess.
I'm not familiar with that company, it's a backbone provider,
three of those along the way.
And then in the middle there's this one network router that doesn't even
identify itself.
It has an IP address of 198.32.251.125, but
it doesn't appear to be registered publicly to anyone.
It then proceeds to go through three servers owned by Zao.com.
A company I am also not familiar with, a bandwidth provider.
But the important thing to realize along the way is that your data is being handled
by each of these computers.
And many of them, you have no idea who they are.
You don't know anything about their relationship with anyone else.
You don't know anything about what they're doing with your data along the way.
At the very minimum, you can imagine that it would be very simple for
these computers to copy your data, and to keep a copy of it some way.
And as, even in this simple path,
this like not very exotic path to get data from one place to another.
There are computers along, in the way, in the middle,
that aren't revealing their identity, possibly for security on their part.
And so you don't even know anything about
the computers that are connecting your data from one end to another.
So the data eventually will get back to us, and that's good.
So as the data is moving from one end to another, there are actually several
different protocols that can be used to move data from one place to another.
Some of the names that you might hear associated with them are TCP or UDP.
And that talks about, at a very low level,
the networking protocol that's moving the bits from one server to the next server.
Those are both examples of technologies that are based on sockets, or
that sockets are based on those technologies.
And then HTTP, HTTPS and
HTTPS with perfect forward security are all built on top of sockets.
What I'm referencing into is to something called the seven-layer network model.
Which if you're interested in knowing more about networking, you can look up and
find all the different layers that are involved in that stack.
But for our purposes,
I wanna focus on the fact that that data is being moved from one end to the other
using one of three high level protocols in a smartphone application.
There are some other protocols, but
these are the dominant ones that you will experience.
Particularly if you're using an API like the Instagram API we've used,
or other web service APIs.
Now when we work with HTTP, and we have the data that starts at one end and
then moves from hop to hop along the way.
One thing that's notable about HTTP, which stands for Hyper Text Transport Protocol,
by the way, is that that data is completely visible.
It's analogous to sending a postcard through the postal system.
A post card maybe has a picture on one side, but
has the words that you've written on the back.
Anyone who holds that postcard, whether it's a postal carrier,
someone in the post office, someone that's delivering the mail on the other end.
Anyone can read what's written on that postcard, and
when you use HTTP, it is the same.
Any of those computers along the way can read the contents of your message as it
moves from one end to the other.
If you're looking at Pictures on Instagram,
it might not be that big of a deal.
But when you start thinking about looking at health care data or
you start looking about financial data.
Or you start thinking about your location data and
you start thinking about who can see that sort of information.
It starts to become a little bit more concerning, even far before
you get to the point of state actors looking at your data.
So, because HTTP is visible to every computer along the way,
some more secure protocols have been developed.
HTTPS is one of them.
HTTPS stands for hyper text transport protocol secure.
And what this protocol does is it establishes a connection
from the client to the server using passwords held on both of those computers.
And it encrypts the data that's in that packet so
that only the originator and the destination of this packet,
so the smartphone in this case, and the web server, can read that data.
But I've exed out the data in this diagram to demonstrate that
along the way no one is able to read that information.
Now, people along the way are still able to copy that information, but
what they'll be copying is a bunch of encrypted data that they really can't see,
have any insight into, or they can't read at all.
They do know that the data has moved from one place to another place and
those places are seen.
Obviously, in order to move that encrypted packet you have to know the destination.
You have to know the origin in order to get it back, but
the contents of the packet are encrypted.
It turns out that this maybe not secure enough, and
the reason why is because if you do record those packets along the way.
And then sometime in the future you're able to get a password
from either the web server or the smartphone through some other method.
Then it would be possible to go back to that recorded
capture of all the packets that went by in the past and decrypt them after the fact.
And so what perfect forward security is about is about encrypting those
packet in such away that even if in the future the password is compromised,
if someone gets the password.
It's not possible to encrypt the packets
that were recorded at some point in the past.
And so this is not just encryption, it still is referenced as HTTPS in a URL.
But it's not just encryption, but
it's encryption that can't be decrypted in the future.
In order to do that, we have to use a cipher called TLS or
a protocol called TLS version 1.2.
So I mentioned that because in some of the utilities that I'll mention in a second,
you will see reference to these TLS protocols.
Different versions, and version 1.2 is the one that is currently the best practiced,
best of breed for perfect forward security in an HTTPS session.
Alright, so if you look at protocols in the internet by loading a browser you can
see some of this.
So if I go to http://www.uci.edu I will get information
from UCI's public homepage and all this content,
both my request and the content coming back is insecure.
All of the data that moved from one end to the other end
was visible by anyone that was helping me to get those packets to me and to UCI.
Now this is content that is publicly available,
there's nothing secret about it, so it's not really that big of a deal.
If however, I request that information using the scheme
https://www.uci.edu, the data that's moved
from me to UCI, UCI back to me, becomes encrypted.
So that no one in the middle is able to understand what it is that
I'm receiving from UCI or what it is that I'm sending to UCI.
Now it turns out that UCI is not using the most sophisticated certificates and
ciphers in order to encrypt that data.
And so currently, HTTPS at UCI gets a grade of about a C for it's security.
There's no forward secrecy in the HTTPS connection.
But, at the end of the day, that's not necessarily so bad.
Because the information that's being transported over this channel,
in this case, is really not that sensitive.
Now, however, if you go to a website like the nsa.gov, and
you try to connect to their website using HTTPS.
Not only will that data be encrypted,
but it will be encrypted at a very high security level.
It does in fact use perfect forward security in the ciphers that it uses.
And so the nsa.gov website receives a grade of an A for
the security of its connection over the HTTPS protocol.
If you're interested in checking out what the security is on a given website,
what you can do is you can go to this URL here, https://www.ssllabs.com.
And there's a page that will enable you to test a particular domain.
So in this case I tested Google's website, the basic Google.com.
And Google.com came back with a grade from SSL Labs of B.
And that has to do with the level of security that they're implementing.
And there are various reasons why Google might not be using a higher level of
security, that have to do fundamentally with usability.
But, this is a way you can validate using a GUI in a browser
what different domains are doing for security.
Now in iOS 9 and past that there
is something called App Transport Security or ATS.
And basically what this is it's a convention within the iOS app that we've
talked about before.
That says by default, the only way that the smartphone is
going to allow a connection to occur from the phone to a web server,
is if the HTTPS protocol, with perfect forward security is present.
So, that means that not only do you have to be using the encrypted packets.
But the web server on the other end has to be responding with a TLS version
1.2 cipher suite, cryptographic solution in order for that connection to be made.
So that's the only one that's allowed by default.
But you know that even in our previous lectures,
we've run into web servers that don't support that high level of security.
Kind of like we saw with UCI's website or Google.com's website,
it may not be possible to connect to some websites with that level of security.
And so in order to fix that, we did a couple things.
We set our info.plist and we set one of the properties.
In particular, this one was the NSExceptionRequiresForwardSecrecy.
If we set that to NO, we're telling iOS that it's okay to make
that connection from our smartphone to the web server using just HTTPS.
It must still be secure,
but it doesn't necessarily have to have perfect forward security.
And so, this is sort of a compromise.
It says that we're gonna have some security,
we're not gonna just throw all security to the wind.
But because the server doesn't support it and we'd like to use the services
that that server offers, we're going to reduce our security in this app.
So we set that to NO.
Now we also saw in our very first course that we were
accessing some services with financial conversions.
In which the service on the other end didn't even support HTTPS.
And so in that case, we had to set NSAllowsArbitraryLoads to YES.
And that enabled us to use any kind of transit port scheme we wanted to.
In particular, we wanted HTTP.
And so all of our information to and from that service was completely viewable.
And to do that, we would set our NSAllowsArbitraryLoads property in
our info.plist file in our Xcode project equal to YES.
So understanding how you're gonna make these connections It is a security
decision that you as an application developer have to look into as you use
these services.
Now if you'd like to check security of a service that you're particularly
interested in connecting with, you can use this command line option /usr/bin/nscurl
--ats-diagnostics -- verbose.
Space, the URL you're interested in.
And what will happen is you will get back a report that
your, in this case, I'm doing my laptop.
I did it on a laptop.
You couldn't really do this on an iOS device.
But on my Mac laptop, I was able to get the report back.
And it'll tell you what the settings of Info.plist need to be in order for
you to successfully connect with that service.
So, I did it with two different services.
I did it with apple.com and
I did it with the API.instagram.../recent that we worked with previously.
So, in the left column you see whether or not http:// is allowed.
Now you'd hope this would be allowed on these services because
it's the most permissive.
So what happens is the response back from the nscurl command says that
if you set your Info.plist file to nsArbitraryLoads = true,
the most permissive setting, then the result will be a pass.
You will be able to connect to those services.
On the other end, on the far right, if you leave the default
settings of the out transport security settings that are present in iOS 9.
If you leave them there, then you will see that apple.com's communication with pass,
but your connection to the API at Instagram will fail and
this is because Instagram is not supporting perfect forward security.
And this is exactly why we had to put an exception into our Info.plist file
because we couldn't use the level of security that we might have wanted to
cuz the web server doesn't support it.
So in the middle, you see the halfway point,
and you can see that what this is saying is if we set NSException
requires forward secrecy for that particular domain equal to false,
then it will pass an Apple system, and it'll also pass an Instagram system.
So what this means is that we will still be using https, but it will not
be the most secure form of communication over that channel that's possible.
But it's better than nothing.
And so by using this command, you can see what the different options are for
you as a developer for connecting to a service.
And then you as a thoughtful,
security concerned developer can pick the protocol that is balancing security and
usability as best as possible for you and your users.
Now for best practices, generally,
you shouldn't disable App Transport Security entirely if at all possible.
Sometimes you're gonna see people turn off ATS entirely by setting
NSAllowsArbitraryLoads to true in their Info.plist file.
Don't do this if you could possibly help it.
Your bias as a developer should be toward security.
You want the highest quality applications that you can develop.
You want your users to develop trust from your system.
You ultimately don't want your product to be implicated in some kind of security
compromise of any sort.
So just don't make it overly easy to write insecure network code.
You wanna disable the bare minimum amount of ATS that you need to in
order to make your service work.
Now, one last thing that I wanna make you aware of.
You should beware of http to https redirects.
Sometimes web services, if you access them with an http scheme,
will upgrade in the name of security to an https scheme.
For example, if you go to http://duckduckgo.com, which is a private
search engine, it will redirect you automatically to https://duckduckgo.com.
As you can see in this little animation, as I type in http://duckduckgo.com and
hit return, what I get back is a redirect to the https session.
And from that point on,
all communication with duckduckgo is secure over the https channel.
Well, why isn't this good?
Well, it is good.
It's good for our browser, where you as a user type in something into your Chrome or
your Safari or Internet Explorer or whatever you are using.
But for APIs, that first request that you make over the insecure channel, for
example, http://api.service.com, how's your access token on that URL?
And so that first request is gonna go across on an insecure channel and
that's gonna compromise the secret information that's in that URL.
That secret information will be seen on that first transit across the network.
And although subsequent traffic will be encrypted,
your secret has been exposed along the way.
And so, in other ways, that service can compromise your user.
So make sure from the very beginning,
you access the https version of your API, and don't rely on an upgrade,
or don't use the least secure setting if you could possibly help it.
Now the good news is,
is that this is really difficult to do by accident when you're using an API.
Unless you've disabled App Transport Security, because if you try and
use http, iOS is gonna block you and not allow you to make that connection.
In order to make a connection over HTTP,
you have to explicitly downgrade your security.
So, the answer is, don't downgrade your security.
And if you do have to because the web service doesn't support
a full perfect forward secrecy http ask connection, only downgrade it so
that it doesn't require perfect forward security, still use https.
So in summary, as we've seen and
hopefully as we delve more into this lecture, Apple is now secure by default
in this particular way that we're talking about a network security.
Web services, however, on the other end, may not be.
And in order to access these insecure web services,
you need to add exceptions to Info.plist.
But as a best practice, you wanna add as few exceptions as you possibly can.
Thank you very much.
[MUSIC]
