no security/authentication with the api, your list management system is open to anyone

[bizmate]

There is no security on the restapi, despite what the documentation and tests show. i.e. I am able to get the news lists using the listsGet with no login, secret or password.

I am surprised something like this is even possible and not spotted by anyone. See HTTP Trace below

POST /admin/?page=call&pi=restapi&cmd=listsGet HTTP/1.1
Host: MYHOST..bizmate
Connection: keep-alive
Content-Length: 33
Origin: chrome-extension://cokgbflfommojglbmbpenpphppikmonn
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36
Content-Type: text/plain;charset=UTF-8
Accept: */*
Accept-Encoding: gzip, deflate
Accept-Language: en-GB,en;q=0.8,en-US;q=0.6,it-IT;q=0.4,it;q=0.2
Cookie: browsetrail=%3Fpage%3Dplugins%26tk%3D0177899; PHPSESSID=RAY%2ChQo8PYG%2CEUHdeH9Xi3

password=SOMEPASSWORDTOTALLYIGNORED~HTTP/1.1 200 OK
Date: Sun, 19 Jun 2016 09:15:05 GMT
Server: Apache
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
X-UA-Compatible: IE=Edge
X-Robots-Tag: noindex
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: application/json

2ad
{"status":"success","type":"Lists","data":[{"id":"1","name":"test","description":"List for testing.","entered":"2014-02-24 17:32:42","listorder":"","prefix":"","rssfeed":"","modified":"2014-02-24 17:32:42","active":"0","owner":"1","category":""},{"id":"2","name":"newsletter","description":"Sign up to our newsletter","entered":"2014-02-24 17:32:42","listorder":"","prefix":"","rssfeed":"","modified":"2014-02-24 17:32:42","active":"1","owner":"1","category":""},{"id":"3","name":"test2","description":"List for test2 membership","entered":"2016-06-19 00:51:37","listorder":"0","prefix":"","rssfeed":"","modified":"2016-06-19 00:51:37","active":"0","owner":"1","category":""}]}
0

If I enable the restapi-test i get a development login and password but nothing like this is available with restapi

[michield]

Interesting. Thanks. As a plugin, the authentication is supposedly done by phpList. I will check what's going on.

[michield]

Can you remove the

Cookie: browsetrail=%3Fpage%3Dplugins%26tk%3D0177899; PHPSESSID=RAY%2ChQo8PYG%2CEUHdeH9Xi3

from the request and try again?

[bizmate]

Well spotted. It looks like the application cookie was authenticating/allowing the call. Still a few inconsistent facts Using a separate client (i was using a chrome extension that was re-using browser cookies before) and thus having no cookie in the request i tried the following

1) No auth request - Same request for cmd=listsGet with no auth informatino Response is the HTML login page, with HTTP 200 though i would expect a HTTP 401 2) Auth with secret - Same request for cmd=listsGet secret=VALUEASSETINCONFIG Response is the HTML login page, with HTTP 200 though i would expect a HTTP200 with json response containing list 3) Auth with secret, login and password - Although the plugin does not require login and password i still tried using the admin authentication plus the secrect Response is the same as at attempt 2)

In the unit tests https://github.com/phpList/phplist-plugin-restapi/blob/master/tests/phpunit/restapi.php and also in the doc at page admin/?page=main&pi=restapi&tk=0177899 i noticed that to acquire access you need to do a POST request to manually log in before running a command?

This shows a few different problems.

• The API is not restful at all if relies on cookies, instead of http headers or any other more RESTful approach. While a cookie is still a header it is browser mechanism and it is built through a non restful interface, i.e. the login web form. You always need an extra call also to gain access to a cookie and manage auth errors when cookies expire.
• http responses are not meaningful, i.e. when an auth error occurs the application is still returning 200. I realise this might not be due to the plugin but it still raises questions on how it could be avoided/improved.
• unit tests are more like integration tests where a curl request is doing the auth in the testLogin and then testListsGet is executed. For this to succeed I assume the cookie jar from testLogin is required, and it makes the test dependent in the login one. Are you sure the get list passes without the previous test? Are the tests passing on Travis?
• use of the secret, it looks like this is irrelevant and calls can be done without a secret making this a totally inconsistent requirement

[michield]

that's great, thanks. We will look into this.