Explore
For Enterprise
Join for Free
Log In

艺术与人文
商务
计算机科学
数据科学
信息技术
健康
数学和逻辑
个人发展
物理科学与工程
社会科学
语言学习
學位
證書

瀏覽 Coursera 的全部課程

瀏覽
搜索
企業版
登錄
免費加入

Network Security Considerations

Loading...

iOS 应用的网络与安全

加州大学尔湾分校

4.6（239 個評分） | 12K 名學生已註冊

課程 2（共 6 門，面向创意企业家的 iOS 开发專項課程）

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

查看授課大綱

審閱

4.6（239 個評分）

5 stars
176 ratings
4 stars
38 ratings
3 stars
15 ratings
2 stars
5 ratings
1 star
5 ratings

KE

Mar 21, 2016

Really good information, good quality presentation. The working examples are well chosen and fun to work along with. Thank you!

SR

Apr 25, 2016

Great course, cuts right to the chase. I'm reviewing the lessons which I hope never turns off. thanks Coursera

從本節課中

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?

NSAppTransport in iOS 910:26

Network Security Considerations22:16

Getting data with NSURLSession10:26

Calling and Parsing API JSON data7:38

教學方

Don Patterson
Associate Professor
Sam Kaufman
Partner 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]

探索我們的目錄

免費加入並獲得個性化推薦、更新和優惠。

Coursera 致力於普及全世界最好的教育，它與全球一流大學和機構合作提供在線課程。

© 2019 Coursera Inc. 保留所有權利。

通過 App Store 下載

通過 Google Play 獲取

Coursera
關於
管理團隊
工作機會
目錄
證書
MasterTrack™ 證書
學位
企業版
政府版

社區
Learners
Partners
Developers
Beta Testers
Translators

連接
博客
Facebook
領英
Twitter
Instagram
YouTube
技術博客

更多
條款
隱私
幫助
內容訪問
媒體
聯繫我們
目錄
附屬公司