> POST method is more secure than GET method, > as the values in the POST method are not > cached in the URL. Actually this statement is wrong on both counts. If the POST request is not followed by a redirect (3xx) then using the history to revisit the page may make the browser resubmit the values entered (often prompting a warning that this will happen, none-the-less). A POST may put arguments in the body of the request, but in the specific example given the question is about an argument in the URI. As to whether this argument is a problem, or should be there at all, is all contextual to the application. Querying the account ID like this, with it in the URI, fits the RESTful model, so is valid from that perspective. It all depends on whether the account ID is considered sensitive information. Martin...

If you are worried about sensitive information ending up in apache logs etc., then POST request with parameters in the URL have the exact same problem as GET requests. If however the sensitive information is in the request body, it will not. Erlend On Thu, Jun 27, 2013 at 8:48 AM, Martin O'Neal <martin.oneal@corsaire.com>wrote: > > > POST method is more secure than GET method, > > as the values in the POST method are not > > cached in the URL. > > Actually this statement is wrong on both counts. > > If the POST request is not followed by a redirect (3xx) then using the > history to revisit the page may make the browser resubmit the values > entered (often prompting a warning that this will happen, none-the-less). > > A POST may put arguments in the body of the request, but in the specific > example given the question is about an argument in the URI. > > As to whether this argument is a problem, or should be there at all, is > all contextual to the application. Querying the account ID like this, with > it in the URI, fits the RESTful model, so is valid from that perspective. > > It all depends on whether the account ID is considered sensitive > information. > > Martin... > > _______________________________________________ > The Web Security Mailing List > > WebSecurity RSS Feed > http://www.webappsec.org/rss/websecurity.rss > > Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA > > WASC on Twitter > http://twitter.com/wascupdates > > websecurity@lists.webappsec.org > http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org >

Thanks erlend I think I completely forgot this valid point for getting logged and security concerns and something that I myself mentioned in the email. Thanks martin. I will discuss your point too when I put my suggestion. Thanks Gautam On 27/06/2013 5:03 PM, "Erlend Oftedal" <erlend@oftedal.no> wrote: > If you are worried about sensitive information ending up in apache logs > etc., then POST request with parameters in the URL have the exact same > problem as GET requests. If however the sensitive information is in the > request body, it will not. > > Erlend > > > On Thu, Jun 27, 2013 at 8:48 AM, Martin O'Neal <martin.oneal@corsaire.com>wrote: > >> >> > POST method is more secure than GET method, >> > as the values in the POST method are not >> > cached in the URL. >> >> Actually this statement is wrong on both counts. >> >> If the POST request is not followed by a redirect (3xx) then using the >> history to revisit the page may make the browser resubmit the values >> entered (often prompting a warning that this will happen, none-the-less). >> >> A POST may put arguments in the body of the request, but in the specific >> example given the question is about an argument in the URI. >> >> As to whether this argument is a problem, or should be there at all, is >> all contextual to the application. Querying the account ID like this, with >> it in the URI, fits the RESTful model, so is valid from that perspective. >> >> It all depends on whether the account ID is considered sensitive >> information. >> >> Martin... >> >> _______________________________________________ >> The Web Security Mailing List >> >> WebSecurity RSS Feed >> http://www.webappsec.org/rss/websecurity.rss >> >> Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA >> >> WASC on Twitter >> http://twitter.com/wascupdates >> >> websecurity@lists.webappsec.org >> >> http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org >> > >

Hi Guys, If you are sending sensitive data as a part of the payload(request) you could also encrypt the payload and recommend to serve it over HTTPS. I do have some background working with SSOs and we do encrypt the payload even when using HTTPS. On Thu, Jun 27, 2013 at 12:31 AM, Gautam <gautam.edu@gmail.com> wrote: > Thanks erlend > > I think I completely forgot this valid point for getting logged and > security concerns and something that I myself mentioned in the email. > > Thanks martin. I will discuss your point too when I put my suggestion. > > Thanks > Gautam > On 27/06/2013 5:03 PM, "Erlend Oftedal" <erlend@oftedal.no> wrote: > >> If you are worried about sensitive information ending up in apache logs >> etc., then POST request with parameters in the URL have the exact same >> problem as GET requests. If however the sensitive information is in the >> request body, it will not. >> >> Erlend >> >> >> On Thu, Jun 27, 2013 at 8:48 AM, Martin O'Neal <martin.oneal@corsaire.com >> > wrote: >> >>> >>> > POST method is more secure than GET method, >>> > as the values in the POST method are not >>> > cached in the URL. >>> >>> Actually this statement is wrong on both counts. >>> >>> If the POST request is not followed by a redirect (3xx) then using the >>> history to revisit the page may make the browser resubmit the values >>> entered (often prompting a warning that this will happen, none-the-less). >>> >>> A POST may put arguments in the body of the request, but in the specific >>> example given the question is about an argument in the URI. >>> >>> As to whether this argument is a problem, or should be there at all, is >>> all contextual to the application. Querying the account ID like this, with >>> it in the URI, fits the RESTful model, so is valid from that perspective. >>> >>> It all depends on whether the account ID is considered sensitive >>> information. >>> >>> Martin... >>> >>> _______________________________________________ >>> The Web Security Mailing List >>> >>> WebSecurity RSS Feed >>> http://www.webappsec.org/rss/websecurity.rss >>> >>> Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA >>> >>> WASC on Twitter >>> http://twitter.com/wascupdates >>> >>> websecurity@lists.webappsec.org >>> >>> http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org >>> >> >> > _______________________________________________ > The Web Security Mailing List > > WebSecurity RSS Feed > http://www.webappsec.org/rss/websecurity.rss > > Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA > > WASC on Twitter > http://twitter.com/wascupdates > > websecurity@lists.webappsec.org > http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org > > -- *Michael Hidalgo. OWASP Chapter Leader & Researcher* *Blog: http://michaelhidalgocr.blogspot.com*