nickb wrote:
> Hi meep - if it helps, I think some kind of proxy is probably the right
> way to go here, but I find it useful to set out what concerns you are
> addressing when you add features for security to a system e.g. data
> confidentiality / integrity / sender authentication etc. Anyway, whilst
> I'm not an InfoSec expert, I did note some points / questions:
>
> > > >
- Not wanting to expose the LMS JSONRPC protocol to the web:
> proxying -is- exposing this, of course, but sounds like you're
> adding some command validation. Is this better than LMS's though
> e.g. is this to protect against lower-level payload attacks / buffer
> overflows etc that they don't? On the application level, perhaps
> you're whitelisting only safer commands (thus disabling deletion of
> playlists, rebuilding library, powering down the server, DoSing by
> expensive searches etc)? That'd be a very good idea actually ('least
> privilege'
> (https://en.wikipedia.org/wiki/Principle_of_least_privilege), etc)
> and shouldn't be too hard.
- You also have a level of auth by requiring a (quasi-)secret (the
> -userID-), that's good. Hopefully this ID is long and very sparse
> (consider, say, random UUIDs), as a smallish integer (e.g. database
> primary key) will be exposed to brute-forcing ('enumeration attacks'
> (https://www.owasp.org/index.php/Testing_for_User_Enumeration_and_Guessable_User_Account_(OWASP-AT-002))).
> Is there any way for users to change this ID if it gets compromised?
>
- How do you check the connection is coming from the Skill, not
> somewhere else? Some kind of pre-shared secret? (so won't this be
> visible in the [plain-text] source code)? Or are you using
> certificates?
- Does the proxy rate-limit connections in any way, or ban people
> trying (and failing) too many times? These kinds of things are
> usually critical to stop brute-force attacks.
- Is this communication encrypted? Otherwise, everything's just as
> exposed as login forms over HTTP, etc (eavesdropping on local
> wireless / proxies / server logs etc)
> > >
>
> Sorry if that comes across negative / antagonistic, not meant to be.
> Security is really hard; hopefully there's some good food for thought
> / discussion.
No way is that negative. It's super helpful.
I'm even further from experienced with security and, as noted earlier,
I'm aiming for a flexible and fairly secure system but I'm really
enjoying this project as it's a great learning experience for me. I
hadn't written a line of perl before 2 weeks ago and now I'm building
proxy servers.
Though I am finding it a bit frustrating. The version of perl in LMS is
fairly old and doesn't seem to support forks or threads. Also, each
proxy option I try seems to have some drawback or other. For example, I
cannot get the inbuilt http::daemon to respond to POST requests. It's
happy with GET but sent it a POST, it just ignores. I looked at
Mojolicious which is nice as it's completely stand-alone but it also has
a bug that's preventing it working properly. This part is taking a while
and preventing progress on the main skill logic , but it's important to
get right so worthwhile.
I'll have a go at your individual points;
nickb wrote:
>
> Not wanting to expose the LMS JSONRPC protocol to the web: proxying
> -is- exposing this, of course, but sounds like you're adding some
> command validation. Is this better than LMS's though e.g. is this to
> protect against lower-level payload attacks / buffer overflows etc that
> they don't? On the application level, perhaps you're whitelisting only
> safer commands (thus disabling deletion of playlists, rebuilding
> library, powering down the server, DoSing by expensive searches etc)?
> That'd be a very good idea actually ('least privilege'
> (https://en.wikipedia.org/wiki/Principle_of_least_privilege), etc) and
> shouldn't be too hard..
The proxy will only be aware of and process a limited subset of LMS
commands. The basic player selection play/pause, volume, playlist
selection and, possibly, synching. As such, no fundamental library
management functionality will be exposed. Your note has made me think a
little further about how I structure this application, however.
My original plan was to implement all the logic in the cloud-based
skill. Therefore, the skill would send fully-formed LMS JSONRPC commands
to the proxy which would pass them along to the LMS and return the
response to the skill. However, I'm now thinking about maybe passing
simple requests from the skill and having the plug-in manage all the LMS
requests. The benefit of this is increased distribution of logic
processing as well as eliminating exposing the JSON on skill<->plugin
traffic. The down side, of course, is that I'd need to be careful not to
tie the skill logic to the proxy and isolate it into the plug-in. The
other downside is that I'm far more comfortable working in the Node-RED
platform I've selected for skill development than I am in perl.
nickb wrote:
>
> You also have a level of auth by requiring a (quasi-)secret (the
> -userID-), that's good. Hopefully this ID is long and very sparse
> (consider, say, random UUIDs), as a smallish integer (e.g. database
> primary key) will be exposed to brute-forcing ('enumeration attacks'
> (https://www.owasp.org/index.php/Testing_for_User_Enumeration_and_Guessable_User_Account_(OWASP-AT-002))).
> Is there any way for users to change this ID if it gets compromised? .
The userID for the skill is generated by amazon and is unique to the
user for that skill. (if the user uses a different skill, a different
UID will be generated). However, as far as I know, it's not possible to
change the UID in case of compromise short of establishing a separate
Amazon account. The ID is a very long string.
nickb wrote:
>
> How do you check the connection is coming from the Skill, not
> somewhere else? Some kind of pre-shared secret? (so won't this be
> visible in the [plain-text] source code)? Or are you using
> certificates?.
No certificates envisaged bit that's not to say no. I plan to use code
obfuscation here but am aware this may not be sufficient. I need to
think about this one a little more.
nickb wrote:
>
> Does the proxy rate-limit connections in any way, or ban people
> trying (and failing) too many times? These kinds of things are usually
> critical to stop brute-force attacks. .
This is all possible and fairly easily done.
nickb wrote:
>
> Is this communication encrypted? Otherwise, everything's just as
> exposed as login forms over HTTP, etc (eavesdropping on local wireless /
> proxies / server logs etc).
As of now, no. Working on getting the best proxy solution implemented.
But encryption of traffic would of course be an excellent idea,
What I'd like to do is get a basic proxy implementation up and running,
then focus on the skill enhancement so I can get something into the wild
for people to play with. Then, I can come back on focus on enhanced
security such as encryption, certs etc.
Thanks again for the really useful pointers.
------------------------------------------------------------------------
meep's Profile: http://forums.slimdevices.com/member.php?userid=12744
View this thread: http://forums.slimdevices.com/showthread.php?t=106149