API for Directory Web App

Do you have a useful link that involves the Church and the technology discussed on this site? Post your links and resources here.
Post Reply
lukeh
New Member
Posts: 18
Joined: Tue Mar 06, 2018 1:40 pm

Re: API for Directory Web App

#41

Post by lukeh »

Again devinbost you are over-complicating the problem.

(1) The Church does already operate a Single Sign-On system that spans all their properties (e.g. your lds.org login works on FamilySearch). I assume it's OAuth2 under the hood, but I don't know for sure. The Church would have to authorize API keys or similar to use this SSO system in third party apps.

(2) However, more importantly, you don't need to use SSO at all to make this all work, assuming you don't mind giving your login name and password directly to a custom Android app or website (this is the entire purpose of OAuth/OAuth2, to prevent you having to give your creds to a 3rd party -- but it wouldn't matter much for a custom or open source app developed by or for local units to set up and run in their own instance). Critically, the login creds don't have to be stored anywhere, they are only used once to log in to lds.org via an HTTPS request to grab your session cookie, and that session cookie is then sent with each subsequent request to the JSON API.

(3) As I pointed out in my previous response, of course you do need to worry about not sending data unencrypted etc., and you can't store sensitive data locally either, or transmit it to a third party. But if you don't do any of these things, there is actually nothing to crack/hack, since there is no stored personal data, and no leakage of data over an unencrypted connection.
devinbost
New Member
Posts: 31
Joined: Sun Aug 03, 2014 3:39 pm

Re: API for Directory Web App

#42

Post by devinbost »

lukeh wrote:(2) However, more importantly, you don't need to use SSO at all to make this all work, assuming you don't mind giving your login name and password directly to a custom Android app or website (this is the entire purpose of OAuth/OAuth2, to prevent you having to give your creds to a 3rd party -- but it wouldn't matter much for a custom or open source app developed by or for local units to set up and run in their own instance). Critically, the login creds don't have to be stored anywhere, they are only used once to log in to lds.org via an HTTPS request to grab your session cookie, and that session cookie is then sent with each subsequent request to the JSON API.
So, if you were the Church, what would you do if some developer created a web app that was exploited by cross site scripting (for example), resulting in actual lds.org user passwords being intercepted? Or do you have a suggestion for preventing a risk like that from occurring?
lukeh
New Member
Posts: 18
Joined: Tue Mar 06, 2018 1:40 pm

Re: API for Directory Web App

#43

Post by lukeh »

Or do you have a suggestion for preventing a risk like that from occurring?
Absolutely: as the developer, follow all the OWASP guidelines for preventing XSS/CSRF and similar attacks, or only use libraries that have certified that they follow those guidelines.

More to your point, though, as a user of the site, you would almost certainly not be vulnerable, using a site of the type I have described in messages above. There are two main types of XSS attacks: stored and reflected. If all you're storing on persistent storage are relationships between internal record ids, maybe with some other metadata, but you are not storing any ward directory information whatsoever that will be displayed to the user (since all the information has to be pulled from the lds.org API and displayed immediately to screen, without hitting cold storage or transmission to a third party), then there is no way for stored malicious scripts to be displayed to the user. For a reflected attack to work, assuming that each ward that develops an app around the API (or deploys an open source app) deploys their own instance, you would need to have one of the ward leaders be ultra-knowledgeable about web security and also dead set on stealing the password of another leader of a different auxiliary in the same ward, so that they can craft the right sort of malicious spoof email to trick the server into displaying a malicious script to the user (and you would have to have an XSS reflection vulnerability in the site too, which you wouldn't have if you followed the OWASP guidelines, as I mentioned above). But the malicious auxiliary leader gains very little by stealing the password of the non-malicious leader, since they already have their own login into the site anyway, for the same ward, and can see at least the same directory information. And frankly, if you have that sort of problem in your ward council, you have bigger issues to worry about than web security!

But really the security concerns you are worried about are all surrounding hosted web apps that access the lds.org website. For a large number of uses of the JSON API, you wouldn't even produce a hosted site, you would just build a little tool that the clerks or EQ Presidency or RS Presidency can run on their own computers for organizational purposes.

For example, it was just announced that my ward is splitting, but figuring out exactly where to put the new boundary is very difficult when you have to make complex decisions about the distribution of member addresses, priesthood holders, activity rates, proximity to chapels, overlap with other wards/stakes (in the case of singles wards), construction / in-move growth rates, etc. -- there are simply no good tools that the Church has developed to let you see all the information in one place, and slice/dice it (while you pray about it) until you get just the right mix. That is a tool that you can imagine someone creating, putting up on GitHub, and letting any unit download and run it on their clerk computer. There's no need to set up a hosted web server instance to run it, you would just run it locally. And then 100% of the security issues you are worried about reduce to simply, "Is the antivirus software on the PC up to date?"...
devinbost
New Member
Posts: 31
Joined: Sun Aug 03, 2014 3:39 pm

Re: API for Directory Web App

#44

Post by devinbost »

lukeh wrote: Absolutely: as the developer, follow all the OWASP guidelines for preventing XSS/CSRF and similar attacks, or only use libraries that have certified that they follow those guidelines. . . And then 100% of the security issues you are worried about reduce to simply, "Is the antivirus software on the PC up to date?"...
So you're saying that if the Church created the API correctly, it would be impossible for an app created by a member-developer to create a situation that could result in membership data being leaked in a way that could have been prevented if the developer had not been able to have programmatic access to the data? This would include accidents such as a developer accidentally uploading an AWS key to a public github.com repository, allowing their software-engineering savvy relative who posts on Ex-Mormon forums and sells data on the dark web to access their computer with a shared computer login, cases where the member-developer thinks they know more about security than they actually do, cases like where they are still using a machine running Windows XP or they end up with a rootkit that their anti-virus didn't detect, as well as other security risks that could be introduced by inexperienced or ignorant member-developers?
jonesrk
Church Employee
Church Employee
Posts: 2361
Joined: Tue Jun 30, 2009 8:12 am
Location: South Jordan, UT, USA

Re: API for Directory Web App

#45

Post by jonesrk »

lukeh wrote:For example, it was just announced that my ward is splitting, but figuring out exactly where to put the new boundary is very difficult when you have to make complex decisions about the distribution of member addresses, priesthood holders, activity rates, proximity to chapels, overlap with other wards/stakes (in the case of singles wards), construction / in-move growth rates, etc. -- there are simply no good tools that the Church has developed to let you see all the information in one place, and slice/dice it (while you pray about it) until you get just the right mix. That is a tool that you can imagine someone creating, putting up on GitHub, and letting any unit download and run it on their clerk computer. There's no need to set up a hosted web server instance to run it, you would just run it locally. And then 100% of the security issues you are worried about reduce to simply, "Is the antivirus software on the PC up to date?"...
Actually the stake leaders that do the ward split have access to a very nice tool to divide wards and see how the changes impact numbers on the fly. I've used it in a couple of ward splits in my stake and they were much easier than the ones I worked on before the tool was available.
lukeh
New Member
Posts: 18
Joined: Tue Mar 06, 2018 1:40 pm

Re: API for Directory Web App

#46

Post by lukeh »

So you're saying that if the Church created the API correctly, it would be impossible for an app created by a member-developer to create a situation that could result in membership data being leaked in a way that could have been prevented if the developer had not been able to have programmatic access to the data?
Yes, I split this into two cases in my previous message: hosted and non-hosted. For hosted, it would be a tiny server instance run by each unit, and it wouldn't store any membership data (only organizational metadata), so XSS vulnerabilities are a non-issue for all the reasons I described. For running organizational tools locally, XSS isn't an issue at all, because you're not even running on a server -- the only thing you have to worry about is keylogger viruses -- *but* you have the same exact threat of leaking your password via a keylogger virus every time you log into lds.org from any device, so this is no less safe than just logging into the Church's own website in a browser!
Actually the stake leaders that do the ward split have access to a very nice tool to divide wards and see how the changes impact numbers on the fly. I've used it in a couple of ward splits in my stake and they were much easier than the ones I worked on before the tool was available.
Thanks, I hadn't seen that. I have been a clerk seven times before, but this must have been released after my time!

I gave the ward division tool suggestion only as an example of the sort of tool you might want to develop using the API -- there are many more things that I and others have needed over the years that would be useful to do with a proper API (hence the number of times people have posted to LDSTech asking about API access...).

Actually what I would love to see is for the Church to open-source all their code, for both websites and mobile apps, then we could all just dive in with any spare time we wanted to donate, and help add features to those, rather than wanting to develop external apps that work through an API. I think there were a couple of Church Android apps that were open source at one point, but were later turned into closed source projects (Gospel Library? Or LDS Tools? Anybody remember the history?).
devinbost
New Member
Posts: 31
Joined: Sun Aug 03, 2014 3:39 pm

Re: API for Directory Web App

#47

Post by devinbost »

lukeh wrote:
So you're saying that if the Church created the API correctly, it would be impossible for an app created by a member-developer to create a situation that could result in membership data being leaked in a way that could have been prevented if the developer had not been able to have programmatic access to the data?
Yes, I split this into two cases in my previous message: hosted and non-hosted. For hosted, it would be a tiny server instance run by each unit, and it wouldn't store any membership data (only organizational metadata), so XSS vulnerabilities are a non-issue for all the reasons I described. For running organizational tools locally, XSS isn't an issue at all, because you're not even running on a server -- the only thing you have to worry about is keylogger viruses.
Okay... So, what method would you employ on the Church side of the API to prevent data from being stored in the member-developer application after it is transmitted across the wire? A legal agreement? How would you programmatically detect if the terms had been violated so that access could be immediately revoked and the Church's legal team could be notified before much damage had been done? Would the member-developer be required to implement a library on the client side that continuously monitors all of the user's files and network I/O? That would open some pretty major privacy issues on its own, among other issues.
lukeh
New Member
Posts: 18
Joined: Tue Mar 06, 2018 1:40 pm

Re: API for Directory Web App

#48

Post by lukeh »

You would put the same type of usage restrictions on the API as are currently shown on PDFs generated from lds.org, and printouts from MLS -- "For official Church use only" or similar (though you would maybe be more explicit about not transmitting the data to third parties or storing it in persistent storage), then you would trust that people who have a calling that should give them API access will do the right thing with the data. This is the very standard of expectation the Church applies already to membership data.

The Church already can't stop anyone from copying the whole ward directory and publishing it on a public website, or selling it to telemarketers etc. -- but they have to believe that the overwhelming majority of the time, that simply won't happen, and the good uses far outweigh the potential bad -- while giving every member the ability to unlist themselves from the directory at any time if they care about misuse of their data.

There will always be tradeoffs between how locked down or controlled data is, and its usefulness.
User avatar
johnshaw
Senior Member
Posts: 2272
Joined: Fri Jan 19, 2007 1:55 pm
Location: Syracuse, UT

Re: API for Directory Web App

#49

Post by johnshaw »

lukeh wrote:
Actually what I would love to see is for the Church to open-source all their code, for both websites and mobile apps, then we could all just dive in with any spare time we wanted to donate, and help add features to those, rather than wanting to develop external apps that work through an API. I think there were a couple of Church Android apps that were open source at one point, but were later turned into closed source projects (Gospel Library? Or LDS Tools? Anybody remember the history?).
There was an army of volunteers are first, they quickly figured out the 'pace' the church was willing to go and found better things to do with their time. The church and open source philosophies are just not compatible, otherwise we'd have had come, follow me 2 decades before it happened, we'd have 2 hour church with 4 to 5 wards per building so you don't have wards the size of an international stake. we're a top-down org.
“A long habit of not thinking a thing wrong, gives it a superficial appearance of being right, and raises at first a formidable outcry in defense of custom.”
― Thomas Paine, Common Sense
devinbost
New Member
Posts: 31
Joined: Sun Aug 03, 2014 3:39 pm

Re: API for Directory Web App

#50

Post by devinbost »

I think giving individual members the ability to opt-in and opt-out in a controlled way to each specific API consumer (meaning each specific member-developer-created application) that desires to access their data would be the only possible way I could see something like this happening. In such a case, the liability to the Church would be limited because the Church would be only facilitating interactions between members and member-developers rather than forcing members to either allow their data to be used or not used in some particular way. Members who don't opt-in to a particular API consumer simply wouldn't have their data visible to that application, and if a member opts-in to no applications, their data wouldn't be available to the API at all for anyone. This approach could also give the Church administrative control because if a particular API was violating the terms of usage of the member data in any way, the Church could revoke the authorization, and this could be controlled either at a general level or at a ward or stake level, depending on how the Church wanted to do it.
Post Reply

Return to “Links & Resources”