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@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@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@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@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 list
Aerogear-users@lists.jboss.org
https://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 list
Aerogear-users@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


_______________________________________________
Aerogear-users mailing list
Aerogear-users@lists.jboss.org
https://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 list
Aerogear-users@lists.jboss.org
https://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 list
Aerogear-users@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