Hey Fred,
Thanks for the response. The search parameters are of course included in
the initial GET request, but as best I can tell from the log output they
are not included when the user is sent back to the referring page. As to
your question about the cookies, I'm not sure. I've been using logger.debug
to inspect the session, but I may be missing something. Here's what I've
got in my search action right now:
def search
session[:return_to] ||= request.referer
if !params[:search].numeric?
flash[:error] = %Q[<i class="fa fa-times fa-fw"></i> Please enter a numeric
student ID.].html_safe
logger.debug("@@@@ flash: #{flash}")
logger.debug("@@@@ session: #{session}")
logger.debug("@@@@ request.referer: #{request.referer}")
redirect_to session.delete(:return_to)
else...
The following two gists contain the log output I'm seeing from Chrome and
Safari. Comments are mine.
- Chrome - https://gist.github.com/joshukraine/7975903
- Safari - https://gist.github.com/joshukraine/7975914
I'd love to understand more about inspecting cookies, requests, and so
forth. If there's more I can do I'm happy to try. Thanks for your help!
Josh
On Sunday, December 15, 2013 1:24:23 PM UTC+2, Frederick Cheung wrote:
>
>
>
> On Thursday, December 12, 2013 7:09:21 PM UTC, joshukraine wrote:
>>
>> Hey Fred,
>>
>> thanks for the reply. I've thought about the caching issue, though I'm
>> not sure how to tell if this is in fact the problem. I'm not specifically
>> caching anything in my app, and I've cleared out the localhost data for
>> Safari. Also, all other flash notices in the app work fine, only this one
>> sticks.
>>
>> Have you looked at whether the search parameters are being included in
> the links? Although if you're not going to the search action I would assume
> that they wouldn't be used even if they were.
>
> Have you tried inspecting the individual http requests coming back? The
> Set-Cookie response header should be showing you changes to the session
> your rails app is making, and obviously the Cookie header on requests
> contains the current session data (The cookie value has two parts,
> separated by --. The second part is the signature, and the first part is
> base64 encoded marshal data so somehting like
> Marshal.load(Base64.decode64('...')) should turn the data back into a ruby
> object). Does the cookie on the next request contain the set-cookie value
> from the previous request? (I have in the past seen race conditions with
> sessions, although only with overlapping http requests)
>
>
>
>> As I was discussing this issue with another developer, I decided to make
>> a couple of short screen recordings (YouTube) that demonstrate what this
>> looks like in Safari as compared to Chrome and Firefox. If it helps, you
>> might have a look at these. Perhaps you'll notice something that I'm
>> missing.
>>
>
>
>> Also, many thanks for the observation about the XSS bug. So far I have
>> not been able to reproduce it though. For example, I entered this:
>> 99999999<script>alert('bad news!')</script>. The search action did see it
>> as numeric, but it stripped out the javascript and just returned a flash
>> saying that a student with ID 99999999 could not be found. I also tried
>> entering it via the URL, but that just crashed the redirect saying "cannot
>> redirect to nil". I guess I thought that Rails was sanitizing this
>> somewhere in the background, but maybe not. Any suggestions?
>>
>>
> My apologies, your code is fine. It's worth you understanding how the
> rails sanitization works though
>
> When you do
>
> %Q[<i class="fa fa-warning fa-fw"></i> Sorry, we couldn't find a student with
> ID #{id}.].html_safe
>
> you are telling rails that everything in that string is safe. So if id
> contained something untrusted, you'd be in trouble. However, since you
> called .to_i on that earlier on you're fine (I'd skipped over that line)
>
> Fred
>
>
On Sunday, December 15, 2013 1:24:23 PM UTC+2, Frederick Cheung wrote:
>
>
>
> On Thursday, December 12, 2013 7:09:21 PM UTC, joshukraine wrote:
>>
>> Hey Fred,
>>
>> thanks for the reply. I've thought about the caching issue, though I'm
>> not sure how to tell if this is in fact the problem. I'm not specifically
>> caching anything in my app, and I've cleared out the localhost data for
>> Safari. Also, all other flash notices in the app work fine, only this one
>> sticks.
>>
>> Have you looked at whether the search parameters are being included in
> the links? Although if you're not going to the search action I would assume
> that they wouldn't be used even if they were.
>
> Have you tried inspecting the individual http requests coming back? The
> Set-Cookie response header should be showing you changes to the session
> your rails app is making, and obviously the Cookie header on requests
> contains the current session data (The cookie value has two parts,
> separated by --. The second part is the signature, and the first part is
> base64 encoded marshal data so somehting like
> Marshal.load(Base64.decode64('...')) should turn the data back into a ruby
> object). Does the cookie on the next request contain the set-cookie value
> from the previous request? (I have in the past seen race conditions with
> sessions, although only with overlapping http requests)
>
>
>
>> As I was discussing this issue with another developer, I decided to make
>> a couple of short screen recordings (YouTube) that demonstrate what this
>> looks like in Safari as compared to Chrome and Firefox. If it helps, you
>> might have a look at these. Perhaps you'll notice something that I'm
>> missing.
>>
>
>
>> Also, many thanks for the observation about the XSS bug. So far I have
>> not been able to reproduce it though. For example, I entered this:
>> 99999999<script>alert('bad news!')</script>. The search action did see it
>> as numeric, but it stripped out the javascript and just returned a flash
>> saying that a student with ID 99999999 could not be found. I also tried
>> entering it via the URL, but that just crashed the redirect saying "cannot
>> redirect to nil". I guess I thought that Rails was sanitizing this
>> somewhere in the background, but maybe not. Any suggestions?
>>
>>
> My apologies, your code is fine. It's worth you understanding how the
> rails sanitization works though
>
> When you do
>
> %Q[<i class="fa fa-warning fa-fw"></i> Sorry, we couldn't find a student with
> ID #{id}.].html_safe
>
> you are telling rails that everything in that string is safe. So if id
> contained something untrusted, you'd be in trouble. However, since you
> called .to_i on that earlier on you're fine (I'd skipped over that line)
>
> Fred
>
>
On Sunday, December 15, 2013 1:24:23 PM UTC+2, Frederick Cheung wrote:
>
>
>
> On Thursday, December 12, 2013 7:09:21 PM UTC, joshukraine wrote:
>>
>> Hey Fred,
>>
>> thanks for the reply. I've thought about the caching issue, though I'm
>> not sure how to tell if this is in fact the problem. I'm not specifically
>> caching anything in my app, and I've cleared out the localhost data for
>> Safari. Also, all other flash notices in the app work fine, only this one
>> sticks.
>>
>> Have you looked at whether the search parameters are being included in
> the links? Although if you're not going to the search action I would assume
> that they wouldn't be used even if they were.
>
> Have you tried inspecting the individual http requests coming back? The
> Set-Cookie response header should be showing you changes to the session
> your rails app is making, and obviously the Cookie header on requests
> contains the current session data (The cookie value has two parts,
> separated by --. The second part is the signature, and the first part is
> base64 encoded marshal data so somehting like
> Marshal.load(Base64.decode64('...')) should turn the data back into a ruby
> object). Does the cookie on the next request contain the set-cookie value
> from the previous request? (I have in the past seen race conditions with
> sessions, although only with overlapping http requests)
>
>
>
>> As I was discussing this issue with another developer, I decided to make
>> a couple of short screen recordings (YouTube) that demonstrate what this
>> looks like in Safari as compared to Chrome and Firefox. If it helps, you
>> might have a look at these. Perhaps you'll notice something that I'm
>> missing.
>>
>
>
>> Also, many thanks for the observation about the XSS bug. So far I have
>> not been able to reproduce it though. For example, I entered this:
>> 99999999<script>alert('bad news!')</script>. The search action did see it
>> as numeric, but it stripped out the javascript and just returned a flash
>> saying that a student with ID 99999999 could not be found. I also tried
>> entering it via the URL, but that just crashed the redirect saying "cannot
>> redirect to nil". I guess I thought that Rails was sanitizing this
>> somewhere in the background, but maybe not. Any suggestions?
>>
>>
> My apologies, your code is fine. It's worth you understanding how the
> rails sanitization works though
>
> When you do
>
> %Q[<i class="fa fa-warning fa-fw"></i> Sorry, we couldn't find a student with
> ID #{id}.].html_safe
>
> you are telling rails that everything in that string is safe. So if id
> contained something untrusted, you'd be in trouble. However, since you
> called .to_i on that earlier on you're fine (I'd skipped over that line)
>
> Fred
>
>
On Sunday, December 15, 2013 1:24:23 PM UTC+2, Frederick Cheung wrote:
>
>
>
> On Thursday, December 12, 2013 7:09:21 PM UTC, joshukraine wrote:
>>
>> Hey Fred,
>>
>> thanks for the reply. I've thought about the caching issue, though I'm
>> not sure how to tell if this is in fact the problem. I'm not specifically
>> caching anything in my app, and I've cleared out the localhost data for
>> Safari. Also, all other flash notices in the app work fine, only this one
>> sticks.
>>
>> Have you looked at whether the search parameters are being included in
> the links? Although if you're not going to the search action I would assume
> that they wouldn't be used even if they were.
>
> Have you tried inspecting the individual http requests coming back? The
> Set-Cookie response header should be showing you changes to the session
> your rails app is making, and obviously the Cookie header on requests
> contains the current session data (The cookie value has two parts,
> separated by --. The second part is the signature, and the first part is
> base64 encoded marshal data so somehting like
> Marshal.load(Base64.decode64('...')) should turn the data back into a ruby
> object). Does the cookie on the next request contain the set-cookie value
> from the previous request? (I have in the past seen race conditions with
> sessions, although only with overlapping http requests)
>
>
>
>> As I was discussing this issue with another developer, I decided to make
>> a couple of short screen recordings (YouTube) that demonstrate what this
>> looks like in Safari as compared to Chrome and Firefox. If it helps, you
>> might have a look at these. Perhaps you'll notice something that I'm
>> missing.
>>
>
>
>> Also, many thanks for the observation about the XSS bug. So far I have
>> not been able to reproduce it though. For example, I entered this:
>> 99999999<script>alert('bad news!')</script>. The search action did see it
>> as numeric, but it stripped out the javascript and just returned a flash
>> saying that a student with ID 99999999 could not be found. I also tried
>> entering it via the URL, but that just crashed the redirect saying "cannot
>> redirect to nil". I guess I thought that Rails was sanitizing this
>> somewhere in the background, but maybe not. Any suggestions?
>>
>>
> My apologies, your code is fine. It's worth you understanding how the
> rails sanitization works though
>
> When you do
>
> %Q[<i class="fa fa-warning fa-fw"></i> Sorry, we couldn't find a student with
> ID #{id}.].html_safe
>
> you are telling rails that everything in that string is safe. So if id
> contained something untrusted, you'd be in trouble. However, since you
> called .to_i on that earlier on you're fine (I'd skipped over that line)
>
> Fred
>
>
On Sunday, December 15, 2013 1:24:23 PM UTC+2, Frederick Cheung wrote:
>
>
>
> On Thursday, December 12, 2013 7:09:21 PM UTC, joshukraine wrote:
>>
>> Hey Fred,
>>
>> thanks for the reply. I've thought about the caching issue, though I'm
>> not sure how to tell if this is in fact the problem. I'm not specifically
>> caching anything in my app, and I've cleared out the localhost data for
>> Safari. Also, all other flash notices in the app work fine, only this one
>> sticks.
>>
>> Have you looked at whether the search parameters are being included in
> the links? Although if you're not going to the search action I would assume
> that they wouldn't be used even if they were.
>
> Have you tried inspecting the individual http requests coming back? The
> Set-Cookie response header should be showing you changes to the session
> your rails app is making, and obviously the Cookie header on requests
> contains the current session data (The cookie value has two parts,
> separated by --. The second part is the signature, and the first part is
> base64 encoded marshal data so somehting like
> Marshal.load(Base64.decode64('...')) should turn the data back into a ruby
> object). Does the cookie on the next request contain the set-cookie value
> from the previous request? (I have in the past seen race conditions with
> sessions, although only with overlapping http requests)
>
>
>
>> As I was discussing this issue with another developer, I decided to make
>> a couple of short screen recordings (YouTube) that demonstrate what this
>> looks like in Safari as compared to Chrome and Firefox. If it helps, you
>> might have a look at these. Perhaps you'll notice something that I'm
>> missing.
>>
>
>
>> Also, many thanks for the observation about the XSS bug. So far I have
>> not been able to reproduce it though. For example, I entered this:
>> 99999999<script>alert('bad news!')</script>. The search action did see it
>> as numeric, but it stripped out the javascript and just returned a flash
>> saying that a student with ID 99999999 could not be found. I also tried
>> entering it via the URL, but that just crashed the redirect saying "cannot
>> redirect to nil". I guess I thought that Rails was sanitizing this
>> somewhere in the background, but maybe not. Any suggestions?
>>
>>
> My apologies, your code is fine. It's worth you understanding how the
> rails sanitization works though
>
> When you do
>
> %Q[<i class="fa fa-warning fa-fw"></i> Sorry, we couldn't find a student with
> ID #{id}.].html_safe
>
> you are telling rails that everything in that string is safe. So if id
> contained something untrusted, you'd be in trouble. However, since you
> called .to_i on that earlier on you're fine (I'd skipped over that line)
>
> Fred
>
>
--
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to rubyonrails-talk+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/rubyonrails-talk/6a2cb3df-8163-44ea-bc38-68899a04ff28%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
