Is it possible to have IIS require SSL and redirect HTTP at the same time?

Question

I have 2 file upload in my form, i.e. Formik form with initialValues which is this

  const initialValues = {
    coverPhoto: this.props.response.response.coverPhoto
      ? this.props.response.response.coverPhoto
      : {},
    photo: this.props.response.response.photo
      ? this.props.response.response.photo
      : {}
  };

and the form

<Formik initialValues={initialValues}  onSubmit={fields => { this.props.onUpdateMyProfile(fields); }>
....
<input type="file" className="custom-file-input" id="photo" name="photo" accept="image/*" onChange={event => setFieldValue( "photo", event.currentTarget.files[0])}/>
<input type="file" className="custom-file-input" id="coverPhoto" name="coverPhoto" accept="image/*" onChange={event =>"coverPhoto", setFieldValue(event.target.files[0])} />

but when I submit the form it is getting me {} an empty object instead of the File Object, but when I console it out, I get the whole Object, along with the image object.

aboutYourself: "e4 e5 c4"
coverPhoto: ""
firstName: "Yash"
lastName: "Karanke"
photo: File
lastModified: 1605275591390
lastModifiedDate: Fri Nov 13 2020 19:23:11 GMT+0530 (India Standard Time) {}
name: "pngtree-abstract-background-image_88872.jpg"
size: 636889
type: "image/jpeg"
webkitRelativePath: ""
__proto__: File
slug: "yash-karanke"

. How do I resolve it?

Solution 1

If you turn on Require SSL then HTTP requests will fail immediately.

One trick we used (using ASP.NET) before doing the same was to check for the protocol on the default page, then issue a friendly warning, e.g.

If Not Request.IsSecureConnection Then
    loginform.visible = False
    ltl_warning.Text = "Non-secure connections will be disabled in one month, please use the secure address only: https://mysite.com"
End If

Solution 2

The "Require SSL" still responds without SSL, so MITM attacks are still a possibility.

To secure the site, you should use the redirect, and then send the Strict-Transport-Security header, so that after the first visit, the users browser won't event attempt to connect without using SSL.

Further Reading

• HTTP to HTTPS redirects on IIS 7.x and higher - Not related to STS
• How to enable HTTP Strict Transport Security (HSTS) in IIS7+

Comments

[userSteve]

Whats the security reasons for not using the redirect?

[Erwin Rooijakkers]

A redirect is slightly insecure because of possible motm attacks. See security.stackexchange.com/a/107106

[Erwin Rooijakkers]

Thanks. If we have Require SSL this default page cannot be reached right? So this display page would be a temporary one for some time before the full switch. I guess there is no way around it?

[Erwin Rooijakkers]

could you look at my answer?

[EvilDr]

Yes, that's exactly right.

[Erwin Rooijakkers]

EvilDr, could you look at my answer and comment on if this is secure?

[EvilDr]

In terms of secure, what is the content you are trying to protect? You should not redirect to SSL on the client side because apparently it is susceptible to man-in-the-middle attacks. The user should have to click a link manually to switch to the SSL-based site, so I wouldn't use JavaScript if possible.

[EvilDr]

To be honest I'd be tempted to email your HTTP users and tell them, as some might not be logging in frequently anyway. Then, once its HTTPS only, you'll soon find out where the gaps are!

[EvilDr]

As above, JS redirects aren't recommended due to man-in-the-middle attacks and spoofed redirect pages. I can't find the link to prove this as I read it ages ago, but a link the user has to click on to get to HTTPS is better.

[Code Ninja]

Yes, I have added that and it is still not working

[Nilesh Patel]

still i can see 1 param event =>"photo", setFieldValue(event.target.files[0]

[Code Ninja]

oh, I edited the question with an incorrect code.

[g.pickardou]

Since when attacks are coming from browsers? "...still responds without SSL...", what kind of response?

[bradlis7]

@g.pickardou Man in the middle means that there's a device between the PC or browser and the server. Not the browser itself. A device could send the user trying to go to "bankly.com" to their own site ("bank1y.com") that looks the same, which allows them to trick the user into giving them info intended for the first site (login info or worse).