টমক্যাটে এইচটিটিপি পদ্ধতিগুলি অস্বীকার করা মামলা সংবেদনশীল?


11

আমি আমার অ্যাপ্লিকেশনটির ওয়েব.এক্সএমএলগুলিতে পুট, ডিলেট, ইত্যাদি বাতিল করার চেষ্টা করার জন্য নিম্নলিখিতটি রেখেছি put

 <security-constraint>
 <web-resource-collection>
  <web-resource-name>restricted methods</web-resource-name>
  <url-pattern>/*</url-pattern>
  <http-method>DELETE</http-method>
  <http-method>PUT</http-method>
  <http-method>SEARCH</http-method>
  <http-method>COPY</http-method>
  <http-method>MOVE</http-method>
  <http-method>PROPFIND</http-method>
  <http-method>PROPPATCH</http-method>
  <http-method>MKCOL</http-method>
  <http-method>LOCK</http-method>
  <http-method>UNLOCK</http-method>
  <http-method>delete</http-method>
  <http-method>put</http-method>
  <http-method>search</http-method>
  <http-method>copy</http-method>
  <http-method>move</http-method>
  <http-method>propfind</http-method>
  <http-method>proppatch</http-method>
  <http-method>mkcol</http-method>
  <http-method>lock</http-method>
  <http-method>unlock</http-method>
 </web-resource-collection>
 <auth-constraint />
 </security-constraint>

ঠিক আছে, তাই এখন:

আমি যদি পদ্ধতিতে অনুরোধ করি তবে আমি DELETE403 ফিরে পাব।

আমি যদি পদ্ধতিতে অনুরোধ করি তবে আমি delete403 ফিরে পাব।

কিন্তু

আমি যদি পদ্ধতিতে অনুরোধ করি তবে আমি DeLeTeঠিক হয়েছি!

আমি কীভাবে এগুলিকে এই সংবেদন-সংবেদনশীলতা বর্জন করতে পারি?

সম্পাদনা করুন: আমি এটি সি # প্রোগ্রাম দিয়ে পরীক্ষা করছি:

    private void button1_Click(object sender, EventArgs e)
    {
        textBox1.Text = "making request";
        System.Threading.Thread.Sleep(400);
        WebRequest req = WebRequest.Create("http://serverurl/Application/cache_test.jsp");
        req.Method = txtMethod.Text;
        try
        {
            HttpWebResponse resp = (HttpWebResponse)req.GetResponse();

            textBox1.Text = "Status: " + resp.StatusCode;

            if (resp.StatusCode == System.Net.HttpStatusCode.OK)
            {
                WebHeaderCollection header = resp.Headers;
                using (System.IO.StreamReader reader = new System.IO.StreamReader(resp.GetResponseStream(), ASCIIEncoding.ASCII))
                {
                    //string responseText = reader.ReadToEnd();
                    textBox1.Text += "\r\n" + reader.ReadToEnd();
                }
            }
        }
        catch (Exception ex)
        {
            textBox1.Text = ex.Message;
        }
    }

txtMethod.Textএকটি পাঠ্য বাক্স যেখানে আমি পদ্ধতির নাম টাইপ করছি। যখন 403 থাকে তখন একটি ব্যতিক্রম ছুঁড়ে দেওয়া হয় যা ক্যাচ ব্লকে ধরা পড়ে।

Cache_test.jsp এর মধ্যে রয়েছে:

<%
response.setHeader("Cache-Control", "no-store, no-cache, must-revalidate, post-check=0, pre-check=0");
response.setHeader("Pragma","no-cache");

out.print("Method used was: "+request.getMethod());
%>

আপনি এটি পরীক্ষা কিভাবে?
জাভিয়ের লুকাস

@ জাভিয়ারলুসাস, এটিকে প্রশ্নের সাথে যুক্ত করেছেন
বিকাশকারী

1
আপনার পরীক্ষার প্রোগ্রামটি ত্রুটিযুক্ত। কেস-সংবেদনশীলতার সাথে স্ট্যান্ডার্ড এইচটিটিপি পদ্ধতিগুলিকে বড়হাতে রূপান্তর ও রূপান্তরিতHttpWebRequest করবে । অতিরিক্তভাবে, এটি কেবলমাত্র স্ট্যান্ডার্ড এইচটিটিপি পদ্ধতিগুলির অনুমতি হিসাবে নথিভুক্ত করা হয়েছে। কাঁচা টিসিপি স্ট্রিম (যেমন নেটক্যাট, বা পুটিটি কাঁচা, বা টেলনেট ইত্যাদি) ব্যবহার করা সবচেয়ে ভাল বিকল্প।
বব

1
@ بابি, আমি এটি ভিজ্যুয়াল সি # 2005 এক্সপ্রেসে নেট নেট 2.0 তে করেছিলাম এবং সেগুলির কোনওটিতেই তা চালিত হয়নি। এটি আমি যা টাইপ করছি ঠিক তা পাঠাচ্ছে। সুতরাং তারা অবশ্যই এটি পরবর্তী সংস্করণে পরিবর্তন করেছে।
বিকাশকারী 20

1
@ Bob, লোল মাইক্রোসফ্টের ডকুমেন্টেশন ভুল / বিভ্রান্তিকর। .NET 2.0 সংস্করণের জন্য তারা আরও বলেছে যে "পদ্ধতিটি HTTP 1.1 প্রোটোকল ক্রিয়াগুলির যে কোনওটিতে সেট করা যেতে পারে: GET, Head, POST, PUT, DELETE, TRACE, বা বিকল্পগুলি" " তবে এটি বাস্তবে কোনওভাবেই এটি সীমাবদ্ধ করে না।
বিকাশকারী

উত্তর:


13

টমক্যাটের এইচটিটিপি স্ট্যান্ডার্ড সম্পর্কিত ভুল আচরণ নির্বিশেষে, আপনার একটি কালো তালিকাভুক্তির পরিবর্তে নির্দিষ্ট পদ্ধতিগুলির অনুমতি দেওয়ার জন্য একটি শ্বেতলিস্ট ব্যবহার করা উচিত।

উদাহরণস্বরূপ, নিম্নলিখিত শ্বেত তালিকাটি কেস-সংবেদনশীল GET এবং বাদে সমস্ত পদ্ধতি অবরুদ্ধ করবে HEAD

<security-constraint>
    <web-resource-collection>
        <web-resource-name>restricted methods</web-resource-name>
        <url-pattern>/*</url-pattern>
        <http-method-omission>GET</http-method-omission>
        <http-method-omission>HEAD</http-method-omission>
    </web-resource-collection>
    <auth-constraint />
</security-constraint>

(দ্রষ্টব্য: টমক্যাট +++ প্রয়োজন older পুরানো সংস্করণগুলি ব্যবহার করার জন্য তাদের অন্যান্য সমাধানগুলি যেমন, কোনও সার্লেট ফিল্টারটি তদন্ত করতে হবে))

সূত্র


যখন আমি যে কি পোষ্ট এছাড়াও অন্তর্ভুক্ত সঙ্গে, আমি (শুধু এটা একটি লিঙ্ক বা বুকমার্ক ক্লিক) সাইটে একটি পৃষ্ঠাতে যান এবং এটা আমার একটি 405 দেয়
developerwjk

আসলে এটি আমাকে HTTP স্থিতি দেয় 403 - অনুরোধ করা সংস্থার অ্যাক্সেস অস্বীকার করা হয়েছে
বিকাশকারী

আমি এটি সার্ভারের ওয়েব.এক্সএমএল এ চেষ্টা করেছি এবং এটি বাদ দেওয়া উপেক্ষা করে সবকিছুই অবরুদ্ধ করেছে। ওটা নিয়ে গেছে। অ্যাপ্লিকেশনটির ওয়েব.এক্সএমএল এ চেষ্টা করে এবং আবার এটি কেবল প্রতিটি পদ্ধতি অবরুদ্ধ করে এবং বাদ দেওয়া উপেক্ষা করে।
বিকাশকারীরা

উপরোক্ত হিসাবে ঠিক চেষ্টা করেও বের করে নিল <auth-constraint />এবং তারপরে এটি কেবল সমস্ত কিছুর অনুমতি দেয়।
বিকাশকারী

2
@developerwjk http-method-omissionপ্রথম সার্ভলেট এপিআই 3.0, যা হুল বিড়াল দ্বারা 7+ বাস্তবায়িত হয় এ সংজ্ঞায়িত করা হয়েছে: tomcat.apache.org/whichversion.html । দুর্ভাগ্যক্রমে, এর অর্থ এটি টমক্যাট 6 এবং এর চেয়ে বেশি পুরানোতে কাজ করবে না (দ্রষ্টব্য: 5 ইতিমধ্যে ইওএল)। আপনি লিঙ্কযুক্ত এসও প্রশ্নের অন্যান্য প্রস্তাবিত সমাধানটি চেষ্টা করতে পারেন যা দুটি পৃথক পৃথক সেট নির্ধারণ করার পরামর্শ দেয় security-constraint- আমি নিশ্চিত করতে পারিনি যে একটি ২০১ in সালে কাজ করে, তাই এটি এই উত্তরে অন্তর্ভুক্ত করেনি।
বব

13

ঠিক আছে, কিছু এলোমেলো সার্ভারগুলি Server: Apache-Coyotteতাদের এইচটিটিপি জবাবগুলিতে শিরোনামের স্বাক্ষর রাখার বিষয়ে দ্রুত পরীক্ষা করার পরে , মনে হচ্ছে আপনি get / HTTP/1.1\r\nHost: <target_IP>\r\n\r\nপ্রতিবার সরল নেটক্যাট সংযোগের মাধ্যমে প্রেরণ করছেন যখন 400 টি এইচটিপি কোড পাওয়া উচিত ছিল।

এই ক্ষেত্রে :

$ { echo -en "get / HTTP/1.1\r\nHost: <target_IP>:8080\r\n\r\n" ; } | nc <target_IP> 8080

01:14:58.095547 IP 192.168.1.3.57245 > <target_IP>.8080: Flags [P.], seq 1:42, ack 1, win 115, options [nop,nop,TS val 4294788321 ecr 0], length 41
E..]C.@.@..Y......p.....A..v.......s.......
..D.....get / HTTP/1.1
Host: <target_IP>:8080

[...]

01:14:58.447946 IP <target_IP>.8080 > 192.168.1.3.57245: Flags [.], seq 1:1409, ack 43, win 65494, options [nop,nop,TS val 7981294 ecr 4294787971], length 1408
E...f...i.....p.............A..............
.y....C.HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: text/html;charset=ISO-8859-1
Transfer-Encoding: chunked
Date: Tue, 27 Jan 2015 00:15:14 GMT

আমি অবশ্যই বলতে পারি যে আমি এখানে কিছুটা হতবাক হয়েছি এবং এইরকম আচরণের ক্ষেত্রে এইচটিটিপি / 1.1 পদ্ধতিতে এই আচরণটি প্রসারিত দেখে আমি অবাক হব না।

আপনার বাগ ট্র্যাকিং সরঞ্জামটির উপর একটি বাগ রিপোর্ট পূরণ করা উচিত এবং উপযুক্ত মেলিং তালিকায় একটি মেইল ​​প্রেরণ করা উচিত কারণ এটি খারাপ পরিণতির সাথে আরএফসি 2616 (নীচে দেখুন) এর এক কুরুচিপূর্ণ লঙ্ঘন।

5.1.1 পদ্ধতি

  The Method  token indicates the method to be performed on the
  resource identified by the Request-URI. The method is case-sensitive.

      Method         = "OPTIONS"                ; Section 9.2
                     | "GET"                    ; Section 9.3
                     | "HEAD"                   ; Section 9.4
                     | "POST"                   ; Section 9.5
                     | "PUT"                    ; Section 9.6
                     | "DELETE"                 ; Section 9.7
                     | "TRACE"                  ; Section 9.8
                     | "CONNECT"                ; Section 9.9
                     | extension-method
      extension-method = token

3
দ্রষ্টব্য: আরএফসি 2616 এখন আরএফসি 7230-7235 দ্বারা প্রতিস্থাপিত হয়েছে। আরএফসি 7230 § 3.1.1 : "অনুরোধ পদ্ধতিটি কেস-সংবেদনশীল।" আরএফসি 7231 § 4 : "কনভেনশন অনুসারে, স্ট্যান্ডার্ডাইজড পদ্ধতিগুলি সর্ব-বড় US-ASCII বর্ণগুলিতে সংজ্ঞায়িত করা হয়" ", আপনার উত্তরে একই তালিকা অনুসরণ করা হবে।
বব

1
প্রতিক্রিয়া স্থিতি কোডটি আসলে 405 পদ্ধতিতে অনুমোদিত নয়।
মিথ্যা রায়ান

3
@ লাইরিয়ান না কারণ এর অর্থ হবে যে পদ্ধতিটি টোকেনটি আরএফসি ফিট করে যখন সার্ভার এটিকে এই সংস্থানটিতে ব্যবহার করতে দেয় না। আরএফসি 2616 § 10.4.1: [৪০০ টি খারাপ অনুরোধ] ​​ত্রুটিযুক্ত সিনট্যাক্সের কারণে অনুরোধটি সার্ভারের দ্বারা বোঝা যায়নি। জন্য RFC 2616 § 10.4.6 [405 মেথড না অনুমতি প্রদান করেছে] পদ্ধতি অনুরোধ-লাইন উল্লেখিত সংস্থান অনুরোধ-কোনো URI দ্বারা চিহ্নিত মঞ্জুরিপ্রাপ্ত নয়। টোকেন কোনও উপায়ে এইচটিটিপি পদ্ধতি নয় (উপরে আরএফসি 2616 § 5.1.1 এর অংশ দেখুন)get
জাভিয়ের লুকাস

@XavierLucas: ছোট হাতের পদ্ধতি ব্যবহার করে একটি বাক্য গঠন ত্রুটি নয়, চেক RFC2616 অনুচ্ছেদ 5 । এবিএনএফ-তে extension-methodসিনট্যাক্স tokenরয়েছে যাতে সমস্ত বর্ণানুক্রমিক অক্ষর এবং কিছু চিহ্ন অন্তর্ভুক্ত থাকে, কেবলমাত্র বিশেষত আরএফসি-তে তালিকাভুক্ত পদ্ধতিগুলি। এইচটিটিপি-র প্রায় প্রতিটি অংশই বর্ধনযোগ্য, যতক্ষণ না ক্লায়েন্ট এবং সার্ভার উভয়ই সম্মতি দেয় যে কীভাবে সেগুলিও বাড়ানো হবে, যার সাথে আপনার নিজের ছোট হাতের পদ্ধতিগুলি সংজ্ঞায়িত করা হবে। অনুরোধ লাইন "get / HTTP / 1.1" সিনথেটিকভাবে ঠিক আছে, এটি কেবলমাত্র সেই পদ্ধতিটির নামটি আরএফসি লঙ্ঘন করে কেস সংবেদনশীল হওয়া উচিত।
মিথ্যা রায়ান

@ লাইরিয়ান দ্য রিপোর্টটি extension-methodপরবর্তী আরএফসিগুলির জন্য উন্মুক্ত রেখে এখানে এসেছে, এটি আপনার নিজের পদ্ধতিগুলি আরএফসির সুযোগের বাইরে যুক্ত করার জন্য নয় এবং আপনি যে এইচটিটিপি / ১.১ অনুবর্তী পরিষেবাগুলি চালাচ্ছেন তা ভান করার জন্য এটি এখানে নেই। সুতরাং একটি 400 ফেরত দেওয়া উচিত কারণ সর্বশেষ আরএফসিতে এ জাতীয় কোনও পদ্ধতি এখনও উপস্থিত হয়নি, এটি আজ একটি অবৈধ টোকেন। যদি টোকনটি বর্তমান পদ্ধতির তালিকার সাথে বৈধ ছিল এবং সার্ভার-সাইডটি কার্যকর করা হয়েছে তবে তা অনুমোদিত না হলে 405 ফেরত দেওয়া উচিত। পদ্ধতিটি বৈধ হলেও সার্ভার-সাইড বাস্তবায়িত না হলে একটি 501 ফেরত দেওয়া উচিত।
জাভিয়ার লুকাস
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.