I'm trying to improve my jQuery skills developing a litte website containing a login system.
I'm looking for the best practise and most secure login system.
So far
I had a login.html having a <form action="login.pl">.
On my login.pl I'm connecting to my database and if the user is valid I print a http-redirect to home.html adding my params (?param1=val1¶m2=val2).
Now I took a different way (at least for me a better looking way).
I have a login.html doing an $.ajax request before submit.
The ajax request calls my login.plwhich is returning an json-sting containing a status.
If the json-sting status is success, I return true which results submitting the form <form method="POST" action="home.html">
Now I'm having a few questions:
My form POSTs the password to my home.html.
I believe I have to replace the password value and add some kind of session value to the form to be able to check later if the user session is valid or not. Do I?
How is this done on a professional security level?
I can't access the form data in my home.html as long as I use POST. I try to avoid using GET because professional websites don't have those ugly urls.
How am I supposed to transport username + session id? Do I have to use cookies here?
I didn't really worked with cookies so far, but since user can read cookies, I still won't add any real passwords here and replace password with a session id.
For my understandings: These security requirements won't change even with https. HTTPS provides a secure connection but I still won't save or store any real passwords anywhere on the client.
Related
I want to create an Application (C++) for my schoolmates.
Normally they have to go to our school-website and get to the login site.
There, they type their username and password, login and search for their own class.
I want my application to ask them for class, username and password, send it to the timetable site, download the url and print the timetable for them.
I'm only programming C++ so I don't have a problem with all that except the "sending username and password to the site" step. I know the HTML basics so I think i have to search for the variable names used by the site and send them together with the url somehow? I tried some things but I don't understand how that whole thing works.
<label id="username-lbl" for="username" class="required" aria-invalid="false">
"Benutzername"
<span class="star"> *</span></label>
<input type="text" name="username" id="username" value class="validate-username required" size="25" required aria-required="true" autofocus>
This is the HTML of the Username field. Do i have to write like
...URL....\index.html&username="theusername" because the id is "username" ?
I tried this and it didnt work .. i searched alot on the internet but i dont find an answer.
Before going any further, check the <form> element's method. The way submitted data is sent changes.
If method is GET (or missing), then submitted data is indeed appended to the URL. It is separated from the rest of the URL (as specified by the action attribute) using ? and name-value pairs are separated by &. You also need to properly URL-encode the values.
If method is POST, then data is send in the body of the request. The format depends on the enctype.
Note that there is also the possibility that the data is actually sent using XHR (aka Ajax aka XMLHttpRequest).
The easiest way to get a feel of how things work is to open the Network tab of the Development tools of your favorite browser. It'll tell you whether it's a regular page or XHR, POST or GET, etc.
Note that in many cases, the server will then set cookies to keep state, so you'll have to do the same on your side.
So your C++ program should collect params required and generate valid HTTP POST request.
First you should inspect how that POST request looks like. One of possible ways to do so is using browser developer tools, network tab:
Inspect all headers and bodies. See how these things work and try to make hardcoded request and send it from your C++ program using some HTTP library.
It might authenticate your user and return token or other value that you might use to authenticate requests from your program, and then for other requests include these headers so you can act as a user and fetch user content.
This also depends on authentication implementation, some strategies allow you to do so while some are protected. But I successfully used this technique on production-steady application. I could send various cURL requests and visit pages from my terminal acting as logged in user without logging in or using browser at all. (I didn't login because I just "stole" session from already logged in (and probably remembered) user). In your case you need to login first to obtain these headers (also using your C++ HTTP lib) and then inject new headers to future requests that fetch data.
I am creating a user authentication system using PHP, JQuery, and AJAX. On submit, a request will be sent to 'authenticate.php' with data: username & password using AJAX. The PHP code checks a database for the record and returns 0 on success, 1 on failure. Then if the returned value is 0, the page will be redirected to the 'user private page' using 'window.location="user.php"'.
Now, the question is, is it safe and proper way to authenticate like this? Are there any security problems to use jQuery/JavaScript to redirect page?
Now, the question is, is it safe and proper way to authenticate like this?
Only if inside your user.php you check again if the user has successfully authenticated already. (This is usually where sessions come into play.)
Otherwise, of course everyone who knows the URL of user.php can access it directly.
Are there any security problems to use jquery/js to redirect page?
The only difference between window.location="user.php" (which is wrong, btw. – correct would be window.location.href="user.php") and, say, a normal link to that page, foo, is that the first one happens automatically, and the second one would require the user to click the link first.
So, it is as “secure” as if you had used a simple link. What that actually means here in this case, depends what I said above.
Depends on how secure and compliant you want you application to be. According to RFCs its not recommended to login like that, but keep the form on server side and integrate the login form on frontend (via iframe), then just redirect with redirect url and token, scopes etc to a local html which then eg. sends a window postmessage to your frontend application.
https://www.rfc-editor.org/rfc/rfc6749#page-19
If you just want to be quick and dirty you can go for window.location.href or document.location.href.
Or a bit more secure, send the user to the server and let this be redirected back, but can end up in redirection hell, as its not easy to get back to the state where the user was (including settings and stuff).
Anyways, you will always have to check for the current users's session state whatever you do afterwards with serverside (Sessions).
Since you are working with PHP already i don't recommend using JS to redirect the user. You can use PHP for that:
if($user == $db['user'] && $password == $db['password']){
$_SESSION['logged_in'] = true;
header('location:user.php');
}else{
echo 'username of password is wrong';
}
Then on your user.php file:
if(isset($_SESSION['logged_in'] && $_SESSION['logged_in'] == true){
echo 'welcome to the user page';
}else{
header('location:index.php');//Go back to login page
}
If people go directly to the user.php page, they will be redirected to the index.php page.
I have my website which has this issue. It could be hacked easily through javascript.If the hacker types this in his console he can easily add a user in my database and can signup without going through the stuff like checking password length , checking username length and so on ...
$.post("extra/includes/signup/register.inc2.php",{username:"user1234",email:"email#live.com",p:"here goes password"})
I want a code that could stop him from using console in my website. And if there is no way to do that then how to fix it by some other means ?
Disabling the console won't do. A hacker can always do the same request to your server as you do.
If it is something that isn't public you can protect it using a username and password, looking at the url it is a public script.
If you require a public register script the best way to protect against this kind of thing is to us a captcha (for example recaptcha. It makes it a lot harder to do a scripted attack on your register script.
Always validate the data server side, you can not trust the data you receive from your request because it can be easely manipulated.
You should not rely on client side form validations and it is total bad practice.Try to adapt framework like CI or Laravel . They have particular set of easy ways to validate the form inputs .
I'm using the PHP 5.5+ password_hash() function to hash my passwords before storage in the database. So far so good.
What I am a bit uncertain of is the need of pre-hashing the password that it sent from the form to my PHP script.
Now the form submit procedure is (in short terms) done like this:
HTML file which contains the form calls the controller script in form method=".." ->
Controller script recieves the call and picks the correct function ->
function execution and storage to database.
So basically the call is sent through three files from submit to storage.
I am thinking that somewhere along the line the data could be hijacked and seen in plain view since the hashing is done in the third and final file.
Should I be worried and somehow hash the password with some JavaScript during the initial submission of the form or is it safe? The final site will most likely use an SSL certificate but still I'm not 100% sure if I am safe or not.
Your concerns about hijacking the password between controllers are superfluous :
For an attacker to hijack the password while it's passed between different controllers it would mean the attacker has to be able to read the memory of the PHP process, which would require root privileges. If the attacker has root privileges, you have a bigger problem and your solution won't save you because that same attacker can also modify the PHP files to remove your "protection".
As for hijacking the password while it's flying through the Internet, the only solution is to use HTTPS - whatever Javascript cryptography/hashing you would do is pointless since an eavesdropper is also able to alter the page while it's being transmitted and serve a modified version of it without the additional "security" you added; there are many questions about trying to secure a login form without HTTPS on Security.SE, check them out :
https://security.stackexchange.com/questions/73917/techniques-to-make-a-login-page-safe-without-using-ssl
https://security.stackexchange.com/questions/37655/build-a-secure-channel-without-ssl-tls
https://security.stackexchange.com/questions/41845/login-security-without-ssl
https://security.stackexchange.com/questions/8924/what-is-the-best-way-of-securing-a-website-logon-without-ssl-or-preshared-keys
I have a webpage that is only accessible over http basic auth. How can I figure out the basic auth username in javascript in that page. i.e. when someone visits it (after logging in), I want to make a popup that says "Hello, you're currently signed in as the user $USERNAME"
It's not possible purely from JavaScript. You'd have to have the server side script pick up the username from the request, and insert it in the generated page code for the script to pick up. (eg. <script type="text/javascript">var username=(insert JSON-encoded string here);</script>.
javascript:window.alert(document.location) seems to give a URL with a username (but no password). This may not be true in other browsers.