[Aerogear-users] Aerogear Unified Push registration through a server backend

Matthias Wessendorf matzew at apache.org
Wed May 20 05:10:33 EDT 2015


yes, that is an issue, right.

However, usually you never sent sent sensitive data, you will use push as a
trigger.
Once the app is opened due to a push, the user has to do a login (e.g.
username:password), than the app receives the real payload.

I understand your concerns, and we have to take a look there, but I'd
always use the above flow.

-M

On Wed, May 20, 2015 at 10:01 AM, Alex Ballesté <alexandre.balleste at udl.cat>
wrote:

>  Hi,
> Yes, I was talking about getting the notifications with another
> deviceToken.
>
> Normal flow:
>
> User Good Guy -> download app -> Auths -> register to UPS sending
>
>     {
>     deviceToken: good_guy_device_token
>     variantID: VID,
>     variantSecret: VS
>     alias: user_good_guy
>     categories: [empty in my case]
> }
>
> Ok - success
>
> Malicious flow:
>
> User Hacker Guy -> download app -> explores the code/debug with Chrome->
> Manipulates the authorization result and goes to the registration line and
> sends:
> {
>     deviceToken: hack_guy_device_token
>     variantID: VID,
>     variantSecret: VS,
>     alias: user_good_guy <--- or other valid username
>     categories:  [empty in my case]
> }
>
> Ok- success
>
> Then teacher sends a message and produces a notification to UPS in which
> 'user_good_guy' is in the list of alias. Then Good guy and Hacker guy will
> receive the notification, each in their devices. Isn't it?
>
> Thanks for the patience with my doubts. You are bringing me a great support
>
> Alex.
>
>
> El 20/05/15 a les 09:33, Erik Jan de Wit ha escrit:
>
> Hi Alex,
>
> I think you didn't get what I was saying before, so you want to
> protect UPS so that these hacker students don't get all the
> notifications. Say I'm such a student so I unpack the cordova app and
> I have the variantId and secret. So I can create a POST on UPS to
> change the alias or category but what I need is also the device token
> that is used by the native push network. If I don't use the same one
> that the app uses then I'll end up registering an second device
> instead of modifying. So in order to modify I'll need to intercept the
> initial POST to UPS see what device token is used then modify that.
> Even if I get that to work the device token changes from time to time
> so I'll only able to get all the notifications for a short period of
> time.
>
> On android I could create my own app that uses the same variantId and
> secret as your app and then register itself as a second device with
> different alias or category. This would not work on iOS as it would
> also have to use the same bundleId, but this is unique and linked to a
> certificate.
>
> So protecting UPS to prevent students from tinkering might not be
> worth the effort as it's not a simple POST to update the alias or
> category.
>
> On Tue, May 19, 2015 at 2:36 PM, Alex Ballesté<alexandre.balleste at udl.cat> <alexandre.balleste at udl.cat> wrote:
>
>  Thanks for your advise Matthias,
>
> I understand that categories are the strong feature of UPS letting you to
> send a push notification to one or more categories and then notification
> will arrive to all devices subscribed to those categories.
> In my case the categories don't help a lot because members of our course
> sites change frequently and maintain this relationship device-categories
> would be very difficult to maintain. For this reason I thought to use alias
> instead of categories.
>
> By the other hand I understand that in the authentication methods you pasted
> me relays security on the APP code execution. If code is native like those
> you put, the risk to be hacked is less than using a framework like cordova.
> I'm using aerogear cordova push plug-in and if I want to authenticate first
> I must do it on JS and it's very vulnerable.
>
> I know that I always have the options of change my development framework
> stack or build my "vitamined" cordova plugin, but I want to look for other
> options first :-D
>
> In the last paragraph I wrote in my last email I mean that in order to use
> cordova plugin you must provide JSON object with parameter senderID,
> variantID, variantSecret. In hybrid apps those parameter are exposed to be
> read them easily and it's also easy to manipulate REST calls to the UPS to
> associate the device to other categories or assign other alias ... just it.
> I was looking to proxy-ing to be sure that alias was the same that the
> username that logged in the Backend.
>
> Sorry for bothering you guys.
>
> Alex.
>
>
>
>
> El 19/05/15 a les 12:03, Matthias Wessendorf ha escrit:
>
>
>
> On Tue, May 19, 2015 at 9:40 AM, Alex Ballesté <alexandre.balleste at udl.cat> <alexandre.balleste at udl.cat>
> wrote:
>
>  Hi Erik, thanks for answering so quickly. I still have some gaps in my
> mind; I'm sure that is because my inexperience in that area. Maybe I was
> wrong choosing UPS for covering use case that was not designed for but I
> still think (correct me if I'm wrong) that this scenario is possible:
>
> Our Learning Management System (LMS) Sakai distributes users into "sites"
> corresponding to courses. Each student belong to many sites. An instructor
> from a course can send announcements, messages, upload resources, etc to a
> particular course site and those are only visible to the members of the
> site.
>
> We would like to reproduce that behaviour with UPS. When a user sends an
> announcement to site (and a checkbox is marked) it sends the notification to
> the Messaging backend who automatically sends the notification with an array
> of alias filled with the "username" of members of that site. It helps to us
> to limit who receives a notification from which site ...
>
>
> we have a category
>
> the users device just subscribes to a category or more.
>
>
>
>
> Now, on the backend, so something like:
>
> final UnifiedMessage unifiedMessage = UnifiedMessage
>     .withMessage()
>        .alert("Some Text")
>        .sound("default")
>     .criteria()
>        .categories("Class A") // or pass in more... if desired
> .build();
>
> sender.send(unifiedMessage, () ->
>     logger.info("successful delivery to UPS returned")
> );
>
>
>
>
>
>
>
>
> Our intention with our APP is to authenticate first, to be sure that is an
> student of our university, so registration to the UPS must be done when auth
> succeed (don't let anybody who downloaded the app register to the UPS if
> don't belong to our institution).
>
>
> yes, we do that too:
> iOS:https://github.com/aerogear/aerogear-ios-cookbook/blob/1.6.x/AeroDoc/AeroDoc/Classes/Controllers/AGLoginViewController.m#L153-L174
> Andrid:https://github.com/aerogear/aerogear-android-cookbook/blob/27b9791713b9c77a2f01600ab487e8467cc62431/AeroDoc/app/src/main/java/org/jboss/aerogear/android/cookbook/aerodoc/activities/AeroDocActivity.java#L158-L167
>
>
> Any time, user can choose to disconnect his account from the APP, so we
> developed that when user disconnects their account from the APP it calls to
> unregister, because we don't want that the APP receives more notifications.
> (Maybe that is our first mistake?)
>
>
> remove the cateory
>
>  I don't know how the UPS protects from another app to use the same
> projectID to register to the service (I'll dive deeper to be sure I'm doing
> things well), but I can't imagine another way to prevent  that a user with
> our APP manipulate the calls to UPS with other alias or categories, exposing
> the notifications created from other LMS sites. I know that it's not a
> critical situation because notifications should be not used to send
> sensitive data, but we would like to prevent it in some way.
>
>
> not sure what you mean here
>
>
>
> Thanks,
>
> Alex.
>
>
>
> El 18/05/15 a les 14:47, Erik Jan de Wit ha escrit:
>
> The problem is that you don't want/need to call unregister in a normal
> flow. Unregister is used for instance when a new version of you app
> drops support for push notifications.
>
> I don't get why you are proxy-ing the requests to UPS, because you
> cannot have 2 applications receiving the same push notifications. On
> iOS the bundle id makes sure of that, and on android there is the
> unique project id. So even if a second app would register with UPS it
> will not get the push notifications.
>
> On Mon, May 18, 2015 at 2:12 PM, Alex Ballesté<alexandre.balleste at udl.cat> <alexandre.balleste at udl.cat> wrote:
>
> Hi, I'm developing a mobile app for android and ios for our University. It
> will use AeroGear Unified Push Server to send notifications to students
> when
> a new announcement is sent in our LMS.
>
> We are developing the app with ionic framework and we are using the
> register
> and unregister process through a custom backend service instead of direct
> from device.
>
> We use the cordova plugin and we call registers and unregister JS methods,
> but we don't point to the push server endpoint, but backend server
> instead.
> Once the Backend server gets the requests it creates a new request to Push
> server providing variantSecret and variantID; the response received is
> sent
> back to the app.
>
> We would like to use this flow for security reasons. We want to avoid that
> the users do their own apps and use those values to register and supply
> alias to get users notifications. So backend handles the security (tokens,
> deviceids, usernames, ... ) and if everything is ok then proxies then
> backend generates a new request fullfilling alias and real authentication
> parameters and the received parameters from app. We achieved the
> registation
> and unregistration, but when unregistration process is done if we do a new
> re-registration then we got a success response, but then notification
> didn't
> arrive.
>
> Has anybody did something similar to this approximation? Do you have any
> advise or trick that would be useful for us?
>
> Thanks in advance
>
> Alex
>
>
>
> --
>
> Alexandre Ballesté Crevillén alexandre.balleste at udl.cat
> ====================
> Universitat de Lleida
>
> Àrea de sistemes d'Informació i Comunicacions
>
> Analista/Programador
>
>
> University of Lleida
>
> Information and Communication Systems Service
>
>
> Tlf: +34 973 702148
>
> Fax: +34 973 702130
>
> =====================
>
> Avís legal/Aviso legal/Avertiment legal/Legal notice
>
>
> _______________________________________________
> Aerogear-users mailing listAerogear-users at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-users
>
>
>
> --
>
> Alexandre Ballesté Crevillén alexandre.balleste at udl.cat
> ====================
> Universitat de Lleida
>
> Àrea de sistemes d'Informació i Comunicacions
>
> Analista/Programador
>
>
> University of Lleida
>
> Information and Communication Systems Service
>
>
> Tlf: +34 973 702148
>
> Fax: +34 973 702130
>
> =====================
>
> Avís legal/Aviso legal/Avertiment legal/Legal notice
>
>
> _______________________________________________
> Aerogear-users mailing listAerogear-users at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-users
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
>
> _______________________________________________
> Aerogear-users mailing listAerogear-users at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-users
>
>
>
> --
>
> Alexandre Ballesté Crevillén alexandre.balleste at udl.cat
> ====================
> Universitat de Lleida
>
> Àrea de sistemes d'Informació i Comunicacions
>
> Analista/Programador
>
>
> University of Lleida
>
> Information and Communication Systems Service
>
>
> Tlf: +34 973 702148
>
> Fax: +34 973 702130
>
> =====================
>
> Avís legal/Aviso legal/Avertiment legal/Legal notice
>
>
> _______________________________________________
> Aerogear-users mailing listAerogear-users at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-users
>
>
>
>
> --
>
> Alexandre Ballesté Crevillén alexandre.balleste at udl.cat
> ====================
> Universitat de Lleida
>
> Àrea de sistemes d'Informació i Comunicacions
>
> Analista/Programador
>
> University of Lleida
>
> Information and Communication Systems Service
>
> Tlf: +34 973 702148
>
> Fax: +34 973 702130
>
> =====================
>
> Avís legal/Aviso legal/Avertiment legal/Legal notice
> <http://www.imatge.udl.cat/avis_legal_lopd.html>
>
> _______________________________________________
> Aerogear-users mailing list
> Aerogear-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-users
>
>


-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-users/attachments/20150520/8793e163/attachment-0001.html 


More information about the Aerogear-users mailing list