Tag Info

New answers tagged

2

A source code disclosure vulnerability is an involuntary disclosure of source code. Since JavaScript code runs client-side, on the browser, it's disclosure is intentional. Under this definition, only exposure of the server-side code is a source code disclosure vulnerability. The example you give actually has the GPL on it, so it's already disclosed ...


4

That is the correct behavior. In the case of client-side JavaScript, it is by design that the script source is sent to the client to be executed. So, the fact that you can manually browse to the URL for the script file is irrelevant. It gives you no more access than the application intends for you to have. A source-code disclosure vulnerability is when ...


4

The streaming server needs to know where to send the video to, thus it is aware of your IP address. Using this IP address, your estimated position can be requested from a so-called geolocation database (which connects networks to locations). This usually is not accurate to street or house level, but most of the time at least resolves the city and country ...


3

In simple terms: Your browser starts to connect to an HTTPS website, asking to use a strong cipher. The attacker intercepts this request and replaces it with one asking to use weak "export-grade" encryption. The server gets this modified request and responds to your browser with an export-grade encryption key. Your browser doesn't notice the key it got is ...


2

Yes, all your assumptions are correct there. As you are including content from addthis.com, your client-side Origin is fully trusting this domain. If there was any compromise to addthis.com, or if addthis.com decided to change the script to do something more invasive then your site would be vulnerable. For example, addthis.com may suddenly decide they want ...


1

you can make it local by giving permission on extention folder in this path C:\Users\*your user*\AppData\Local\Google\Chrome\User Data\Default\Extensions rightclick->security-> select user-> deny all


12

Looks like the certificate is only valid for opensource.apple.com, not www.opensource.apple.com: www.opensource.apple.com uses an invalid security certificate. The certificate is only valid for opensource.apple.com (Error code: ssl_error_bad_cert_domain) You can simply use the former.


5

The server sends the entire certificate chain, up to and possibly including the root certificate, all at once as part of the Server Certificate TLS handshake message: certificate_list This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one ...


0

"as I can verify that the cert isn't spoofed and is signed by a well known CA" And how exactly would you do that? Carry around a printed set of certificate hashes for the CAs you think trustworthy? Still not secure, although it does raise te barrier a little, since what you see on screen is a representation of the data - and hence that can be faked too. ...


0

In short, if you have untrusted computer, you're screwed up. But if you have trusted machine you can still use untrusted network safely, depending on the security implementation of the applications in your system. TLS/SSL is designed specifically to allow trusted machines to connect through untrusted network. Good browsers would have to validate certificate ...


1

On an untrusted computer, you cannot know that no one is eavesdropping. This is just a fact of security -- TLS can protect against a man-in-the-middle, but nothing whatsoever can protect you against someone with administrative access to your computer. Even if you have public key pinning for the site, which means that a rogue CA can't create a fake ...


3

Validating the certificate will be the least of your problems if you're using a computer that you do not have full control over. If you are really worried about security, the bigger problems would probably be: web history buried deep within the hard drive (depending on the way information is accessed) keylogger software forgetting to log out of accounts ...


1

I think there's a real danger of confusing a lot of users, which would make the situation even worse. Trying HTTPS everywhere isn't necessarily a bad idea, but there needs to be some sort of fallback plan for the user when HTTPS isn't available. Many users aren't interested in warning signs, they just want their content. In many cases, protecting the ...


1

The EFF has a plugin for Firefox (including Android), Chrome and Opera. It's called HTTPS Everywhere and it uses rules to make sure you end up on the right site. For example it'll rewrite example.com to https://secure.example.com/ if it knows that the https version only lives on secure.example.com. It even replaces urls inside links etc. ...


1

Any website which requires security should redirect from http:// to https:// automatically. This would make the requirement for the browser to automatically view https:// redundant, and is a simpler solution than having to redirect from https to http for sites without certs. This is something that shouldn't really be done anyway, which means the browser ...


0

Because computers used to be weak and encryption was cpu and internet bandwidth hungry and regarded as uneeded in the infancy of the internet.. You basically pack http in another layer and shove it over the pipe. This extra layer needs to do its own ceremonial tango in order to work, which means extra cpu, extra round trips, extra bandiwdth.. But things are ...


7

There's a bigger issue at play here that would prevent your suggestion. The way many web servers are currently configured, you could actually end up on the wrong website if you defaulted to https. This is not true if you default to http. For example, suppose you have 3 sites all on the same IP address: http://site.a.com http://site.b.com https://site.c.com ...


1

Right now browsers use HTTP by default because it is what has been done for decades. It's not the browser's responsibility to ensure that the website is secure. It relies on the website to make the appropriate redirection and support HTTPS. Typing in google.com will redirect to the HTTPS version just fine. If a website supports HTTPS then it should put ...


13

Well, I can presume that a few reasons exist: Websites are not automatically enabled with https support. Therefore, why should browsers be? Saying that a website is not accessible unless using a specific scheme would be over the heads of a significant number of users. Switching to https is not as simple as it sounds in some cases. Take Stack Exchange for ...


50

Browsers are applications for end-users. While the majority of sites is available by http (even if they just redirect to https) a significant part is not available by https. Thus your proposal would break web surfing for a very large part of the users. It would break in a way they don't understand. Automatically downgrading to http if https fails would not ...


5

If code is served by a large Content Delivery Network (CDN), like Google's CDN, then it is more than likely that you will be hacked through other means. Large CDNs have a lot of money to spend on security, and a CDN is unlikely to be a weak point in your own infrastructure. Once a site hits a certain level of popularity, then it needs to serve static ...


0

If it's important for you that users always access your site via HTTPS, start setting Strict Transport Security headers and then submit for hardcoding in browsers. While not perfect, it's AFAIK the strongest technical (vs educational) measure you can take. (Together with mitigating risks like cookie hijacking if a user does visit over HTTP)


1

The main issue with including scripts from other sites is that they (or even someone that gets to hack their server) might modify the script to include malicious code. Right now you have 2 options that have pretty big "downsides": Reimplementing addthis script would be pretty time consuming, so, I don't think you want to go that way. Also you would have ...


2

Yes, it is a security issue. The included JavaScript runs in the context of your website, which means that it has control over anything that you would have control over. External JavaScript files can harm you by among other: read cookies (eg to steal sessions) read user input (eg to read password inputs) change what the user sees (eg to display ads, ...


0

I do my best to develop code in-house, and make use of "SWAMP" which you can apply for access to. If you have coders in-house, you could implement your own plugin and potentially sell it on the side as an app. in the chrome-store. https://www.mir-swamp.org/ For IE you may be able to simply release a memo with instructions on how to access browser tools, ...


1

You can use Group Policy to install the certificate on the client machines. You will need to bind the certificate to your site through IIS/Apache to complete the process. Keep in mind that you will need to ensure that your internal CA is trusted by your internal clients. I think this is in fact reasonably secure, and one of the use cases that ...


0

"how can I tell that the browser supports SSL 3.0?" http://security.stackexchange.com/a/19097/67377 Similar to what SSLLabs offers is the Webpage "SSL Cipher Suite Details of Your Browser" @ https://cc.dcsec.uni-hannover.de/ with a section titled "Preferred SSL/TLS version". It lists your Browser's preferences and what is being used at the moment. ...


2

Hacking / \ / \ / \ Script Kidde Genius 1>Staight away start 1>Start with basics and move up the ladder. with Tutorials. 2>Program ,program and program in many ...


2

I know it seems at first to be such an enormous field that's it's just too hard to know where to start, so please ignore the abruptness of some of the responses (but do consider the intended communication). This, however is not the right forum for this particular question, as has been mentioned above. This is the place to come when you have a specific ...


4

In the case of Facebook, their SDK allows a website to determine whether a user is logged in: FB.getLoginStatus() allows you to determine if a user is logged in to Facebook and has authenticated your app. There are three possible states for a user: the user is logged into Facebook and has authenticated your application (connected) the user is ...


1

No, since that would imply that Flash or JavaScript does have access to raw hardware, outside of its sandbox. Think opposite, that if a flash applet or JavaScript applet would have this access, it would be possible to build a keylogging website that remained Active across tabs. If you need to protect against keyloggers, I would suggest some sort of 2FA. ...


15

I think what you are noticing is a client-side acknowledgement of your sessions with Facebook, Gmail, etc. If a sharing script originates from facebook.com and you have an active session with that hostname, they will present a streamlined share button (for example) for your account. The website linking you to the script on Facebook cannot see who you are ...


0

If they're wiretapping in some fashion, as is probably the case, then they can see what pages are loaded, likely using MitM attacks on HTTPS to get around most normal privacy guards. Defeating this requires certificate pinning, knowledge of (and un-trusting) what CA their MitM certificate was issued by, or a thorough encrypting proxy like Tor. They can't ...


0

Not if it's your normal browser. He could see if the page in your browser has gone out of focus (e.g. if you open a new tab, click over to a new window, etc.), but that is pretty much it. One course my girlfriend had to endure in the past required her to use a dedicated browser which was a bit more invasive, but she was able to cheat using a secondary ...



Top 50 recent answers are included