I have been told that the design should be done in the sprint for each user story
Correct. Implementing a story as part of a sprint includes doing whatever design activities the team considers are required to accomplish the sprint goal (assuming that it's conducive to delivering working software; i.e. don't just do design, also work on implementation.)
but this would change the sprint backlog because it will generate new tasks derived from the created design what is not good.
The development team is in full control of the sprint backlog, and they can add or remove tasks as they see fit, at any time. What Scrum doesn't allow is for people outside the technical team (Product Owner, stakeholders, etc.) to change the composition of the sprint backlog once the sprint is underway.
That being said, the team should keep an eye on how much work they are adding to the sprint backlog, and whether that will still allow them to reach the sprint goal and keep their initial commitment. They should also be careful not to introduce completely new stories in the sprint backlog: adding new tasks that clarify the original intent, or new work that is discovered as part of doing the committed work is fine, but adding completely new stories is not.
One option would be just to add a full iteration where just design (just the necesary not a whole) is done and will generate taks for the next iteration.
Normally, you should try hard to avoid having "just design" iterations. Try simplifying the story scope, building something smaller, less sophisticated, but that gives a tangible result (in the form of real, running software.) Use that as an opportunity for learning, to identify new items for the backlog to be scheduled for future iterations.