[asterisk-bugs] [JIRA] (ASTERISK-24284) ARI fails to strip whitespace properly on bridge type attribute, allowing for bridges to be created even when provided attribute types conflict

[Jonathan Rose (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-24284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=223089#comment-223089 ] 

Jonathan Rose commented on ASTERISK-24284:
------------------------------------------

This is actually already problematic by the time it gets into httpd_process_request. I don't believe spaces are actually permitted in this at all.

I ran:
curl -v -u "admin":"secret" -X POST "http://localhost:8088/ari/bridges?bridgeId=16e1bbaf-2d96-4bf2-a591-0dc9ab0d8d2d&type=mixing, holding, dtmf_events, proxy_media"

and broke in httpd_process_request immediately after request_line is read from ser->f to see what the request_line looked like and it looked like this:

"POST /ari/bridges?bridgeId=16e1bbaf-2d96-4bf2-a591-0dc9ab0d8d2d&type=mixing, holding, dtmf_events, proxy_media HTTP/1.1\r\n", '\000' <repeats 2639 times>"\224, ٣\270\250\177", '\000' <repeats 18 times>, "\003\000\000\000\000\000\000\000\060\001\272\001\000\000\000\000\n\356\273b\000\000\000\000\236⣸\250\177\000\000\000\000\000\000\000\000\000\000\n\000\000\000\000\000\000\000\240\030HI\250\177\000\000\377\377\377\377\000\000\000\000\070\225/s\250\177\000\000\220"...

and since space is used to delimit the type arguments from the HTTP version, I can only think that it just isn't appropriate to try to separate by spaces in the first place.

Ultimately this arrives in ARI with params looking like

type = "holding,"

and everything after that first space is gone entirely.



I'll wait for some commentary, but my opinion right now is that there isn't any bug here.

> ARI fails to strip whitespace properly on bridge type attribute, allowing for bridges to be created even when provided attribute types conflict
> -----------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-24284
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-24284
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_ari_bridges
>    Affects Versions: 12.5.0
>            Reporter: Pavel Kukin
>            Assignee: Jonathan Rose
>
> Bridge create query
> {noformat}
> curl -v -u "user":"password" -X POST "http://localhost:8088/ari/bridges?bridgeId=16e1bbaf-2d96-4bf2-a591-0dc9ab0d8d2d&type=mixing,holding,dtmf_events,proxy_media"
> {noformat}
> returns 500 error. When type param contains spaces, it works.
> {noformat}
>  curl -v -u "user":"password" -X POST "http://localhost:8088/ari/bridges?bridgeId=16e1bbaf-2d96-4bf2-a591-0dc9ab0d8d2d&type=mixing, holding, dtmf_events, proxy_media"
> {noformat}
> Returned data is:
> {noformat}
> {"id":"16e1bbaf-2d96-4bf2-a591-0dc9ab0d8d2d","channels":[],"name":"","technology":"simple_bridge","bridge_class":"stasis","creator":"Stasis","bridge_type":"mixing"}
> {noformat}
> As you can see type contains only mixing param and this is incorrect behavior. But at least it works.
> When I am using the same parameters separated with commas and spaces in my ari client code it returns 500 error. Weird thing. In previous Asterisk version my client had the same code and here is example how it worked.
> Request: 
> {noformat}
> { type: 'mixing, holding, dtmf_events, proxy_media',
>   bridgeId: 'b1cc1a44-0091-49db-ad62-97d165d70c05' }
> {noformat}
> Response:
> {noformat}
> {"id":"b1cc1a44-0091-49db-ad62-97d165d70c05","channels":[],"name":"","technology":"holding_bridge","bridge_class":"base","creator":"Stasis","bridge_type":"holding"}
> {noformat}
> Returned body had only holding type, which is also wrong. Another weird thing. I think the new ARI has some errors in its param parser. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)