Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<h2>Main Points</h2> <ol> <li>Not give permission for run in the upload directories (an attacker can be from inside).</li> <li>Get all possible user information's that is connect to the server (cookie is only one).</li> <li>Monitor the server and alerts (found/see him, stop him, close the door).</li> </ol> <h2>Answer to</h2> <blockquote> <p>Suppose the user uploaded a bad file that was accessible only in his account; the other user then unwittingly downloads that file, running any executable code that is there. </p> </blockquote> <p>First of all you must not allow to run anything on your uploaded directories, because even your regular users can upload an aspx page and run it and browse your files. The first step for this is to add on your upload directories this web.config (but also set the permissions to not allow to run anything).</p> <pre><code>&lt;configuration&gt; &lt;system.web&gt; &lt;authorization&gt; &lt;deny users="*" /&gt; &lt;/authorization&gt; &lt;/system.web&gt; &lt;/configuration&gt; </code></pre> <p>relative : <a href="https://stackoverflow.com/questions/4288362/ive-been-hacked-evil-aspx-file-uploaded-called-aspxspy-theyre-still-trying">I&#39;ve been hacked. Evil aspx file uploaded called AspxSpy. They&#39;re still trying. Help me trap them‼</a></p> <h2>Stealing the cookies</h2> <p>Lets see how we can identify the user.</p> <ol> <li>Cookie</li> <li>Browser ID</li> <li>Ip including proxy and forward ips.</li> <li>Browser have javascript enable (or not).</li> <li>Direct ask for password.</li> <li>Other file stored on client.</li> </ol> <p>Now, for every logged in session, we can connect the first four information's together, and if any of them change we can log him out and ask again to sign in.</p> <p>Also is critical to connect some how (with a line on the database) the cookie with the logged in status of the user, so if the user log out, no matter if some steal his cookie, not to be able to see the pages - what I mean is the cookie that let him log in must not the only one that we rely on, but also our data to track the status of the user.</p> <p>In this case even if some steal the cookie, if the user log out after some actions, the cookie is not useful any more.</p> <p>So what we do is that we connect the cookie+ip+browser id+javascript information's per login, and if any of them change, we not trust him any more, until log in again.</p> <h2>Cookies</h2> <p>One cookie is not enough. We need at least two cookies, one that work only on secure pages, and is required to be https secure and one that work on all pages. This two cookies must be connected together and this connection must also be hold on server.</p> <p>So if one of this cookie not exist, or the connection is not match, then user again not have permission and need to log in again (with alert to us)</p> <p>relative: <a href="https://stackoverflow.com/questions/2498599/can-some-hacker-steal-the-cookie-from-a-user-and-login-with-that-name-on-a-web-s">Can some hacker steal the cookie from a user and login with that name on a web site?</a></p> <p><a href="https://stackoverflow.com/questions/2498599/can-some-hacker-steal-the-cookie-from-a-user-and-login-with-that-name-on-a-web-s/2511514#2511514">An idea to connect cookies together</a>. With this idea I connect the session cookie with the authentication cookie. </p> <h2>If all fails</h2> <p>There are some steps (or actions) that a hacker follow (do) when get to a site so be able to gain from this window opportunity and left a back door open.</p> <ol> <li>Create a new administrator account.</li> <li>Upload a file to run as browser and executable.</li> </ol> <p>As I say we never allow to be able to upload a file that can be run, so this is easy. The other to create a new administrator account is the one that we need to add an extra password that is not saved to any cookie, or nether exist anyway on client.</p> <p>So for rare actions like, New User from backoffice, change the privilege of the users, delete a user, etc, we need to request a second password every time that only the administrator knows.</p> <p>So second password is the final messure.</p> <h2>One final idea</h2> <p>One idea that I have not made, is to store some how information's on the client other than the cookie, the can not be stolen like the cookies, or even if he can be stolen is hidden somewhere on all the data that is impossible to find it.</p> <p>This infomation's can be an extra id of the user together with the cookie, browser data, IP.</p> <p>I am thing some possible places but not have tested or try them yet in real life. So this is some placed.</p> <ol> <li>Custom extension, or plugin, unfortunately different for every browser that have the ability to save data and then we can use them to communicate with the server. This is required action from the user, to install this plugin - and for regular users this can make him afraid and go.</li> <li>Hidden code inside a good cached image, on the header of it, eg on etag. This also is easy to not work because we can not be sure that the image request to reload...</li> <li>Some other browser abilities, eg to read and use a client certificate, that can be used to exchange encrypted data with the server. This request action from the user to install this certificate, and from our part to create them different for every user. Good for bank accounts but not for simple users.</li> </ol> <p>So this is my ideas... any critic, or a solution (for how to store small information's on client other than the cookie) is welcome. </p> <h2>Implementation</h2> <p>To make it real secure we need to keep track of the user on the server, and on database. A table that connect the user, with the ip, with the browser id, and other status, like if now is log in or not, is a measure that we can use to take decisions.</p> <p>If not be able to use a database, or not like to make it difficult, then the connection can be bu hashing some data together and check if this hash is the same.</p> <p>For example we can set a cookie with the hash of (Ip+BrowserID) and check if this much or not.</p> <h2>Alerts - Log</h2> <p>All the above they try to be automate. How ever I suggest also to show to the user and to the administrator some information's to diagnose and prevent an attack. This information's can be.</p> <p>To the user</p> <ul> <li>Last 10 sign in information's (IP, DateTime, Success or not)</li> <li>Send email on user about some actions (for high security sites), like log in, log out, critical actions.</li> </ul> <p>To the administrator.</p> <ul> <li>Log and show any fail of the connection on the four parametres Cookie+IP+BroserID+Javascript Enable). The more the fail in short time, the more attention required.</li> <li>Check for fail login.</li> <li>Check for page read from user with out cookie enable (or save) and javascript is disabled, because this is how scanner identified from my experience.</li> </ul>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload