Hello everybody, I am interested in surveying how same-origin policy is implemented in Firefox. Also, I would like to understand of how frames and documents are managed. Are there any books that talk about Firefox architecture ? Which portion of the source code implements same-origin policy ? Thank You, Karthick
Karthick Jayaraman wrote: > Which portion of the source code implements same-origin policy ? The core is in caps/, in particular, caps/src/nsScriptSecurityManager.cpp and caps/src/nsPrincipal.cpp. There are various callers that perform same-origin checks. -Boris
I am having problems using signtool with any version of NSS from 3.11 onwards and I wanted to make sure I wasn't missing anything obvious before I submit a bug report. In the past I have used nss-3.9 to sign objects without any problems. I am developing on a linux machine, running ubuntu. Recently I upgraded to gutsy (7.10) and found that the latest version of signtool did not work. Running a command like: signtool -d ~/.mozilla/firefox/idr1qmb5.default/ -l Now results in the message: using certificate directory: /home/pbie003/.mozilla/firefox/ idr1qmb5.default/ signtool: function failed: An I/O error occurred during security authorization. Suspecting some corrupted key files, I have tried removing my firefox profile directory and reinstalling firefox (this didn't help). The above message occurs whether I use my firefox profile directory or a generated certificate directory that I have created using certutil. I have downloaded and built version 3.11.7 of nss tools from source on several platforms and get the same error. (tried on Ubuntu 7.10, Max OS 10.4 and 10.5). I have also downloaded a selection of binaries and found that while release 3.9 and 3.10 both work for me, 3.11, 3.11.5 and 3.11.7 do not.
Same issue here, trying to include a signed javascript file from a dynamic web page. I cannot include and sign the html in the jar file. I would like a syntax like <script src="secure.jar!/script.js" type="text/javascript"> </script> is that doable ? Thanks Lucho On Nov 1, 11:30 pm, MarineW <boite-a-spams-mar... <at> aliceadsl.fr> wrote: > Hello, > > I have to use JavaScripts that require special privileges from Firefox. So I > need to sign theses scripts in JAR files, with NSS tool. > But I have a problem as these scripts are then used from JSP pages. > > It is written here > (http://www.mozilla.org/projects/security/components/signed-scripts.ht...), > the following : > > "The major difference in signing scripts between 4.x and Mozilla is that in > Mozilla, the entire page must be signed, as opposed to only the script > running on the page. For any script to be granted expanded privileges, all > scripts on or included by an HTML page must be signed." > > If I understand this correctly, I have to include HTML pages that call(Continue reading)
Peter, The NSS crowd hangs out in mozilla.dev.tech.crypto. I'm cross posting this there. Please follow up there. peter.bier <at> gmail.com wrote, On 2007-12-10 17:18: > I am having problems using signtool with any version of NSS from 3.11 > onwards and I wanted to make sure I wasn't missing anything obvious > before I submit a bug report. > > In the past I have used nss-3.9 to sign objects without any problems. > I am developing on a linux machine, running ubuntu. Recently I > upgraded to gutsy (7.10) and found that the latest version of signtool > did not work. > Running a command like: > signtool -d ~/.mozilla/firefox/idr1qmb5.default/ -l > Now results in the message: > using certificate directory: /home/pbie003/.mozilla/firefox/ > idr1qmb5.default/ > signtool: function failed: An I/O error occurred during security > authorization. > > Suspecting some corrupted key files, I have tried removing my firefox > profile directory and reinstalling firefox (this didn't help). The > above message occurs whether I use my firefox profile directory or a > generated certificate directory that I have created using certutil. > > I have downloaded and built version 3.11.7 of nss tools from source on > several platforms and get the same error. (tried on Ubuntu 7.10, Max > OS 10.4 and 10.5). > > I have also downloaded a selection of binaries and found that while(Continue reading)
Hi everybody, I've had this idea about how a browser could allow end users to protect themselves against CSRF and similar attacks. You can read about it at http://my.opera.com/haakeyar/blog/csrf-we-need-protection. (I'm sorry for posting it on the community site for the Opera browser, but I just needed a place to post it and I already had an account at Opera, so...) It was also mentioned in the last episode of The Command Line Podcast, at http://thecommandline.net/2007/12/23/news_125/ What do you guys think about this? Is it something that could be implemented some time in the future? Should a bug be filed about it? I understand that this in could be sort of overlapping with bug 117222, but in my opinion it is not exactly the same, even though a solution for this one would be a solution for that one. I also understand that maybe this should be in the wishlist-group instead, but since it is very security-related, I decided to post it here. Feel free to point me somewhere else. Regards, Håkon _______________________________________________ dev-security mailing list dev-security <at> lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Hello, I'm the author of the Torbutton Firefox extension (https://torbutton.torproject.org/dev) which attempts to make Firefox safe to use with the Tor privacy network. I've spent the last few days trying to fix https://bugzilla.mozilla.org/show_bug.cgi?id=409737, but I've been having little luck. In summary, the issue is that javascript event handlers registered with addEvetnListener are not disabled by javascript.enabled or docShell.allowJavascript on pages that are kept open after the toggle. An example of this is at http://fscked.org/transient/firefoxjsbug.html. The reason this bug so serious for Tor security is that when a user toggles Tor from 'on' to 'off' (or the reverse) while leaving their Tabs open, javascript and dynamic content can compromise their anonymity by fetching URLs encoded with unique identifiers after the Tor state has changed. For example, these event handlers make it possible to do such network activity whenever the user's mouse enters the content window. While wading through the Firefox code, it appeared to me that event listeners were handled by most DOM objects via a nsEventListenerManager member instance. Specifically, it seemed to me that nsEventListenerManager::HandleEventSubType should be the codepath for javascript listeners, because it compiled the handler and then called out to nsJSEventListener::HandleEvent. But as far as I can tell, this codepath is actually performing the proper nsScriptSecurityManager::CanExecuteScripts check by calling(Continue reading)
Hi Håkon, Håkon wrote: > I've had this idea about how a browser could allow end users to protect > themselves against CSRF and similar attacks. You can read about it at > http://my.opera.com/haakeyar/blog/csrf-we-need-protection. (I'm sorry for > posting it on the community site for the Opera browser, but I just needed a > place to post it and I already had an account at Opera, so...) ...and what prevents Opera from simply implementing your proposal? I'm just curious what makes you care about other browsers in that respect or are there potential implications (for Opera) if you'd go ahead as the only browser? -- -- Regards Signer: Eddy Nigg, StartCom Ltd. <http://www.startcom.org> Jabber: startcom <at> startcom.org <xmpp:startcom <at> startcom.org> Blog: Join the Revolution! <http://blog.startcom.org> Phone: +1.213.341.0390 _______________________________________________ dev-security mailing list dev-security <at> lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Mike Perry wrote: > While wading through the Firefox code, it appeared to me that event > listeners were handled by most DOM objects via a > nsEventListenerManager member instance. That's correct. > Specifically, it seemed to me > that nsEventListenerManager::HandleEventSubType should be the codepath > for javascript listeners, because it compiled the handler and then > called out to nsJSEventListener::HandleEvent. In the case of addEventListener, aListener in this code is not an nsIJSEventListener. It's an XPCWrappedJS implementing nsIDOMEventListener. When the HandleEvent call happens, you end up in nsXPCWrappedJSClass::CallMethod with the appropriate arguments. > If you are feeling particularly helpful, suggesting any other > codepaths that might still allow Javascript to be executed after > scripts have been disabled would be greatly appreciated as well. I commented on this to some extent in <https://bugzilla.mozilla.org/show_bug.cgi?id=409737#c2>. In brief, "lots of places, with more added every day as new DOM stuff appears". -Boris
Eddy Nigg (StartCom Ltd.) wrote: > Håkon wrote: >>(I'm sorry for >> posting it on the community site for the Opera browser, but I just needed >> a place to post it and I already had an account at Opera, so...) > ...and what prevents Opera from simply implementing your proposal? I'm > just curious what makes you care about other browsers in that respect or > are there potential implications (for Opera) if you'd go ahead as the > only browser? I'm not sure I completely understand what you mean, but I have no direct connection to Opera. It's just that I had signed up on their forums/community, and you get a blog there when you do that. I don't have a "real" blog (and I probably won't create one before I buy my own domain), and I needed a place to post the idea, so I decided to use that blogging service. I have posted about it in the Opera wishlist forum, but with no reply yet. I use both Opera and Firefox, and I therefore care about both, and even if I didn't use Firefox, I'd cared because I wan't people to be secure on the web and if one browser implements it, the others will hopefully follow it. I understand that posting it on the Opera blog service was a little stupid, but I hope you understand. If it is really a problem, I could post the contents of the blog post directly here, but it is a little long, so I won't if you can live with it being there. _______________________________________________ dev-security mailing list dev-security <at> lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
RSS Feed7 | |
|---|---|
54 | |
26 | |
17 | |
14 | |
6 | |
19 | |
10 | |
7 | |
42 | |
25 | |
96 | |
35 | |
239 | |
332 | |
20 | |
13 | |
1 | |
4 | |
27 | |
14 | |
10 | |
12 | |
9 | |
37 | |
21 | |
6 | |
3 | |
26 | |
3 | |
3 | |
10 | |
9 | |
4 | |
22 | |
4 | |
11 | |
40 | |
50 | |
9 | |
15 | |
94 | |
122 | |
3 | |
42 | |
88 | |
16 | |
9 | |
54 | |
30 | |
36 | |
27 | |
40 | |
26 | |
13 | |
43 | |
27 | |
47 | |
60 | |
20 | |
23 | |
14 | |
25 | |
31 | |
13 | |
9 | |
8 | |
24 | |
17 | |
15 | |
14 | |
44 | |
41 | |
87 | |
266 | |
47 | |
11 | |
203 | |
20 | |
10 | |
23 | |
32 | |
8 | |
6 | |
4 | |
3 | |
7 | |
12 | |
11 | |
3 | |
8 | |
46 | |
18 | |
165 | |
205 | |
196 | |
312 | |
219 | |
21 | |
55 | |
15 | |
30 | |
35 | |
40 | |
54 | |
51 | |
29 | |
49 | |
42 | |
31 | |
34 | |
30 | |
91 | |
24 | |
40 | |
58 | |
30 | |
27 | |
29 | |
27 | |
25 | |
31 | |
18 | |
36 | |
46 | |
38 | |
37 | |
26 | |
28 | |
19 | |
37 | |
41 | |
1 |
