I have a Laravel-5.5 application in development with a live test application exposed on Google App Engine. My registration process includes the standard Auth registration from Laravel. The RegisterController then redirects to a profile page if there isn't one for the user already.
public function redirectTo()
{
if (!Auth::user()->profile)
{
return '/profile';
}
else
{
return $this->redirectTo;
}
}
The profile controller creates a new userprofile record for the user automatically as the page loads.
$(document).ready(function ()
{
...
getProfileData(profileId);
...
});
getProfileData() posts to the controller. If ProfileId is empty, the controller creates a new record and sends a verification email to the registered address.
How can a user be created without then being redirected and a profile being created?
Users are being created on the live site without profiles or sent verification emails. The user_agent in the session records for these users appear to be real.
Any ideas about how these users are being created and how to stop it would be most helpful.
I believe that Laravel is actively being attacked by actors that are seeking sites with poor security practices. It starts with visiting the site and getting an active session, Then harvesting the sessions csrf-token and using the token in a non site generated post (crawler?) to the standard Laravel registration route.
Since my site has a two part registration that generates a profile and the profile needs to be verified by a human before access is granted, registering and then ignoring the response's redirect to the profile page gets the partially completed registration.
To stop the resulting database clutter in the users table I changed both the standard authentication routes and the expected fields that are returned from the registration form.
Since these changes I have had no half registered users show up in the database. I'll update this answer if I ever see more of this activity.
Related
I'm currently making an API for a mobile app but I think I'm a bit confused with how email verification and authentication is meant to work. I'm attempting to implement the following flow:
User registers in the mobile app and it sends a request to the API
Laravel creates the user and fires off an email
User receives the email and clicks on the link
Laravel verifies the user and redirects them to the mobile app via deep-link
However when the user clicks the email link a "route login not defined" error is rendered.
Which makes sense, because the user is not authenticated at the time. But am I getting this wrong?
Should I authenticate the user prior to sending the email? And will that work, given that we're using Sanctum rather than "regular" authentication?
Currently this is what I'm doing:
// web.php
Route::get('/email/verify/{id}/{hash}', [EmailVerificationController::class, 'verify'])
->middleware('signed') //note that I don't use the auth or auth:sanctum middlewares
->name('verification.verify');
// EmailVerificationController.php
public function verify(Request $request)
{
$user = User::findOrFail($request->id);
if ($user->email_verified_at) {
return '';
}
if ($user->markEmailAsVerified()) {
event(new Verified($user));
}
return redirect()->away('app://open'); // The deep link
}
Is there any security risk here? Should I at any point authenticate the user before or after they click the link?
I wanted to avoid rendering "web views" as much as possible.
I think that the best way is to implement two different paths based on the source of the user.
Regular email validation for users coming from a browser
The user will just follow the link delivered by email, you can do that with or without authentication (maybe with transparent cookie authentication). If the validation is fulfilled redirect them back to the home page.
Mobile users coming from the mobile application
I would send a PIN (with some kind of expire mechanism) via email and ask them to put it inside the APP to verify the account. This can even be protected with auth middleware using the JWT token with the verification API call.
I don't see any security issue with this last one.
We have an issue with a asp.net core 3.1 MVC application. The application is using the built in asp.net Identity feature. The application is working well for existing users. If you hit any [Authorized] route, you are redirected to the login page as expected.
However, rather than have a registration process in our app, for new users, we onboard them via Stripe Checkout. Upon successful payment, stripe redirects to a specific route in our application /conversion/success/{sessionid} where sessionid is the Stripe session. This action is marked as [AllowAnonymous].
We then pull the necessary customer details from Stripe, create a user in our repository via UserManager<T>. We then call SignInManager<T>.SignInAsync() to sign in the new user, before redirecting the new user to the [Authorized] home page.
This process works perfectly when running locally on our test machines. Also, when running on our production server (Azure App Service) it also works perfectly when we hit the route manually through the browser.
However, when we actually run the process through Stripe, complete a payment and let Stripe redirect the customer, we get a strange behaviour.
The conversion route is hit, the user record is created, the sign in process completes but upon redirection to home page, the authentication middleware takes over, says it's not authenticated and redirects to the login page.
Just to compound matters further, if you then simply type in the home page route in the browser, the user is in fact logged in exactly as expected and the application works perfectly.
Using Fiddler to intercept the calls and look at headers, etc. we can't see why there would be a different behaviour when coming from Stripe as opposed to typing directly. We've even tried redirecting from a different website to our registration process and that works as expected too.
Any idea why we are seeing this behaviour?
---- Update ---
If, rather than redirect to home page at the end of the onboarding process, we simply show a simple View with an anchor link to home page, the user can then go to home page as expected.
Is it possible that you're rendering the page before authentication has been completed? Since UserManager uses a cookie to establish the user's session, authentication needs to complete before any response headers or body is set so that the Set-Cookie header can be sent in the response.
Based on what you described it sounds like the user is hitting the homepage after the redirect without having the authentication cookie. Where I'd start debugging this is by using your web inspector with "Preserve log" turned on and going through the Stripe Checkout process. Then, inspect the headers sent to the browser when you land on the redirect page & make sure the authentication cookie is set.
Between requests to Stripe and SignInAsync it seems possible that there might be a missing await, so the redirect is happening before the authentication context is updated. Hard to say more without seeing your code!
So I know API routes are not supposed to rely on sessions authentication, but my idea was to create some API routes, that could be used if needs be by third-party with proper authentication, but that could also be used internally, ie called to get the data I need for my web pages.
I changed the LoginController so that every time a user logs in, a Personal Access token is generated and stored in the database. When logging out, this token is deleted.
So as not to expose the token to the client side, I would like to use a middleware, that would detect, on an API call, if the request comes from a user who is already authenticated. If that's the case, I would retrieve the Personal Access token that belongs to the user, attach it to the request, and pass it onto the API.
Browser -- Query site.com/api/myRoute --> Middleware adds user's token to request if Auth::check() -- Pass-on request --> Controller
I've created a dummy API route to see if I can detect whether a user is authenticated, but that doesn't seem to work... I guess because the 'auth' middleware is not included.. however, if I do include it, I get redirected to home on every request...
Route::get('/test', function() {
if(Auth::check()) {
dd('Hello logged-in');
} else {
dd('Hello not logged-in');
}
});
Any lead on how to achieve that much appreciated!
I have created a custom login form for an app created in Magento some time ago. Everything worked fine until now. Some of the customers are redirected back to the login form after the login process - on their browsers (if I try to login with their credentials, it's working fine).
So, my guess was sessions and I logged them. Session got it in the correct way.
Login is simple, based on Magento login form:
if ($this->_getSession()->isLoggedIn()) {
$this->_redirect('*/*/');
return;
}
$login = $this->getRequest()->getPost('login');
$session = $this->_getSession();
/* do some password stuff */
// here here
$session->login($login['username'], $client_password);
$this->_loginPostRedirect();
I tested their login and logged the session: Mage_Customer_Model_Session Object - everything OK, looks the same as any other customer sessions.
The last url var for this kind of users is /customer/account/loginPost/.
I repeat: For some customers everything works OK. Also, for the users with problems, I can login myself into the app. What could happen? I saved the sessions in files and then I saved them in db - same results.
Ok, so after days of hard check on Magento, I found the solution.
For Magento 1.7 (and older versions too) the problem comes from user sessions.
Copy the file app\code\core\Mage\Customer\Model\Session.php to your local folder app\code\local\Mage\Customer\Model\Session.php.
Search for public function login($username, $password) and comment the line $this->renewSession();.
Magento can create a SESSION ID for the unsecure domain and another cookie for the secured domain. After that it can mess up when you click browser's Back button - redirecting you to the login page because it cannot find the correct SESSION ID created at login.
I have this web app written in AngularJs that uses cookies to authenticate the requests in a REST API.
Once the user logs in, the cookie is received and saved in the browser and all subsequent requests send the cookie along to the server. There is a 'User' service/object that saves the isLoggedIn and username values (for UI display/flow). Now, if I refresh the 'index' page, the app restarts. This means that my 'User' object will be cleared. I can check the existence of the cookie and, if it exists, I can re-set the User.isLoggeIn as true and go from there, but I still need to get the username, id, etc. So, my question is: should I create some sort of 'ping' endpoint in the API to verify if a cookie is valid? And if so, the API would send me back the user id and username... OR should I persist the user data in LocalStorage (or some similar cross-browser thing) and just assume the user is logged if the cookie exists? Any other subsequent requests to pages that need authentication would be automatically verified. So, this question really only applies to the scenario where the user refreshes the index page - hence, restarting the web app. I want to know the user data because I want to show a 'user homepage' instead of the 'public homepage'.
What do you think?
You should depend on the server for this. Creating something like GetCurrentUser method on the server. If the user is logged on this returns all the properties of the user.
You should even use this server api to get the user data after authentication completes. So the authentication become two step process first the user is authenticated, on success another call is made to server to get current users details.
Using client side local storage for this would not be ideal because you need to do lot of book keeping, in terms of cleaning the logged in user on log out or session expiration.
Also cookies from server would have expiration times an all, and making decision just based on cookie existing on local storage may not be optimal approach.