people always say macs are more safe against viruses. but what about sites that target browsers. what about going to a site or clicking on a link that steals browser info like passwords? all i have is my firewall turned on. you can be cautious while browsing but what if i do go to a site or click a link to a url like that.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
am i less protected against sites that steal cookies?
- Thread starter selvage
- Start date
- Sort by reaction score
That's all still a form of malware. What those types of sites do is tell the browser they're downloading a cookie, but that "cookie" is actually a small piece of malware that then reads the information from your other cookies. They are all written as .exe's, however, and none will or can affect your Mac. You don't have anything to worry about.
Plus, if it makes you feel safer, passwords are stored in the Keychain on a Mac, at least in Safari and Chrome, and that's an encrypted storage location that isn't in danger of being breached.
jW
Plus, if it makes you feel safer, passwords are stored in the Keychain on a Mac, at least in Safari and Chrome, and that's an encrypted storage location that isn't in danger of being breached.
jW
There has never been a virus in the wild that runs on Mac OS X. The handful of trojans that exist can be easily avoided with some education and common sense and care in what software you install:
Cookies are stolen via eavesdropping (MITM) attacks and cross-site scripting. Cookies on a Mac can be stolen via these methods.
Being the victim of these types of attacks can be avoided using encryption and blocking third party elements on webpages.
Information concerning avoiding cookie theft can be found in both the security and cookie related links located below in my sig.
Being the victim of these types of attacks can be avoided using encryption and blocking third party elements on webpages.
Information concerning avoiding cookie theft can be found in both the security and cookie related links located below in my sig.
Last edited:
Deleting a cookie will not prevent cookies being stolen when first created and transmitted when using a website; for example, on a website that uses a cookie to maintain authentication and does not use any session encryption. Theft can be avoided by making sure you are not the victim of a MITM attacks. These attacks are only likely on public networks unless private network is not properly secured or includes untrustworthy users. Session encryption prevents the exposure of cookie data if the cookie is stolen so it is beneficial to both use encryption and prevent eavesdropping.
For those interested in more information, read the links in my sig.
Last edited:
Encryption and blocking third party elements on webpages provides some protection from cross site scripting. The padlock icon will not appear or will provide warning on webpages with some types of insecure webpage elements so some scripts that attempt to steal a cookie when injected into a webpage will be detectable if you follow proper procedures related to verifying encrypted connections. Also, sometimes these scripts are injected in third party elements, such as ads, so blocking the ads (and their scripts) reduces exposure to such attacks.
Safari already contains some basic mitigations to prevent XSS (cross-site scripting). The ability to perform these attacks do not represent a flaw in the browser but is due to vulnerabilities in web applications that allow malicious scripts to be run by the browser so they are difficult to prevent from the client-side software.
In many instances, XSS attacks are used to deliver payloads that would require privilege escalation exploit or authentication by user to install. When a payload is delivered, the security mitigations within the OS prevent installation.
In other instances, XSS attacks are used to steal authentication cookies to hijack web application sessions. To perform this type of attack, the attacker must a) embed the script in the webpage, b) send users a malicious url with embedded scripts that links to the vulnerable webpage, or c) inject scripts into the communication between client/server using MITM.
a) Embedding a script into a webpage is easy on webpages where users can post information to be viewed by others, such as on social networking sites. This would allow the theft of the cookies related to that specific site regardless of encryption. Ads on websites can be used in a similar manner. On encrypted connections, the lock icon may not appear or may indicate that insecure elements exist on the page in some instances of this type of XSS attack so manually verifying the digital certificate before logging in is important. This is a good example as to why different passwords should be used for security sensitive sites.
Embedding a script directly into the encrypted login webpage of websites where users can not post data is much more difficult. Banking websites typically have this type of login. This would require the compromise of the server hosting the webpage so that the webpage content could be modified.
b) Malicious urls with embedded scripts could be used to deploy an XSS attack on security sensitive logins, such as the logins for banks, if the webpage contains an XSS vulnerability. Again, the lock icon may indicate insecure elements exist on the webpage. The best practice to avoid this type of attack is to never login to security sensitive webpages from links in emails, email attachments, or instant messages even if the credentials for the webpage appear to be safe.
c) Make sure that the network you are using is secure. Do not login to security sensitive webpages on networks with unknown/untrusted users and use a utility to detect MITM attacks.
In many instances, XSS attacks are used to deliver payloads that would require privilege escalation exploit or authentication by user to install. When a payload is delivered, the security mitigations within the OS prevent installation.
In other instances, XSS attacks are used to steal authentication cookies to hijack web application sessions. To perform this type of attack, the attacker must a) embed the script in the webpage, b) send users a malicious url with embedded scripts that links to the vulnerable webpage, or c) inject scripts into the communication between client/server using MITM.
a) Embedding a script into a webpage is easy on webpages where users can post information to be viewed by others, such as on social networking sites. This would allow the theft of the cookies related to that specific site regardless of encryption. Ads on websites can be used in a similar manner. On encrypted connections, the lock icon may not appear or may indicate that insecure elements exist on the page in some instances of this type of XSS attack so manually verifying the digital certificate before logging in is important. This is a good example as to why different passwords should be used for security sensitive sites.
Embedding a script directly into the encrypted login webpage of websites where users can not post data is much more difficult. Banking websites typically have this type of login. This would require the compromise of the server hosting the webpage so that the webpage content could be modified.
b) Malicious urls with embedded scripts could be used to deploy an XSS attack on security sensitive logins, such as the logins for banks, if the webpage contains an XSS vulnerability. Again, the lock icon may indicate insecure elements exist on the webpage. The best practice to avoid this type of attack is to never login to security sensitive webpages from links in emails, email attachments, or instant messages even if the credentials for the webpage appear to be safe.
c) Make sure that the network you are using is secure. Do not login to security sensitive webpages on networks with unknown/untrusted users and use a utility to detect MITM attacks.
Last edited: