Toon posts:

[C#] ActiveX in webpagina

Pagina: 1
Acties:

Verwijderd

Topicstarter
Hallo,

Ik ben op dit moment bezig met een stuk C# code (ActiveX) wat ik niet aan de praat krijg. Wanneer ik deze code embed in een webpagina krijg ik direct een security exception.

Exception:
System.Security.SecurityException: Request for the permission of type System.Net.SocketPermission, System, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 failed.

De code zou een luisterende socket op de client moeten openen.

Deze code zou moeten werken (volgens mij) indien ik de dll installeer op de gebruikers PC (met een classid). Maar hoe zou ik dit installeren voor elkaar moeten krijgen?
Ik heb dit probleem al eerder gehad tijdens een vorig projectje van mij met een Shoutbox, het ging toen om code welke alleen lokaal werkte maar niet op een ander systeem welke de webpagina opvraagt (daar had GoT mij toen helaas nog niet mee kunnen helpen). Misschien heeft iemand anders inmiddels een heldere kijk op de zaak.

Ik heb de volgende zaken al uitgeprobeerd, maar tot nu toe tevergeefs:
- een classid meegeven bij embedden van bestand.
- een cab bestand genereren met VS .NET
- een cab bestand maken voor de DLL inclusief .inf bestand met behulp van externe tools

Is er iemand die een werkend voorbeeld heeft van een simpele applicatie in C#, voor een soortgelijke situatie, want ik weet niet precies waar ik de oplossing voor het probleem moet zoeken.

De code:

Als code heb ik een GUI (System.Windows.Forms.UserControl) en een klasse Listener welke door de GUI wordt aangeroepen. De GUI zelf bevat weinig ingewikkelds. De listener code ziet er als volgt uit :


C#:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
using System;
using System.Net;
using System.Net.Sockets;
using System.IO;
using System.Security.Permissions;

    
public class Listener
{
    private IPAddress localIP;
    private int localPort = 0;
    private TcpListener tcpListener;
    private NetworkStream networkStream;        
    private StreamReader streamReader;
    private string line;
    private Socket socketForClient;
    private GUI gui;

    public Listener(IPAddress ip, int port, GUI guiObject)
    {                   
        gui = guiObject;            
        localIP = ip;
        localPort = port;

        try
        {
            tcpListener = new TcpListener(localIP,localPort);           
            gui.ShowLog("tcpListener initalised\n");
        }
        catch(Exception ex)
        {
            gui.ShowLog("Exception in Listener:Listener(): " + ex.ToString());
        }
    }

    public void Listen()
    {
        try
        {           
            tcpListener.Start();
            gui.ShowLog("tcpListener started");
            
            //Accepts a new connection...               
            socketForClient = tcpListener.AcceptSocket();
            gui.ShowLog("tcpListener Socket Accepted");

            if (socketForClient.Connected)
            {
                networkStream = new NetworkStream(socketForClient);             
                streamReader = new StreamReader(networkStream);
                
                gui.ShowMessage("Client Connected");

                while(GUI.appRun)
                {   
                    line = streamReader.ReadLine();                 
                    gui.ShowMessage(line);                      
                } 
            }

            socketForClient.Close();            
            gui.ShowLog("Exiting...");          
        }
        catch(Exception ex)
        {
            gui.ShowLog("Exception in Listener:Listen(): " + ex.ToString());        
        }
    }       
}

[ Voor 4% gewijzigd door Verwijderd op 20-06-2005 14:13 ]


  • Janoz
  • Registratie: Oktober 2000
  • Laatst online: 04-05 14:55

Janoz

Moderator Devschuur®

!litemod

"daar had GoT mij toen helaas nog niet mee kunnen helpen" is niet helemaal juist. Ik denk dat het eerder is "Het niet willen accepteren dat de ontwerp beslissing die gekozen zijn in strijd zijn met de heersende opinie met betrekking tot spy, ad en malware"

Het is gewoon niet toegestaan om als untrusted van internet gedwonloade code bepaalde acties uit te voeren. En daarvoor zijn heel goede redenen.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


Verwijderd

Topicstarter
Het is gewoon niet toegestaan om als untrusted van internet gedwonloade code bepaalde acties uit te voeren. En daarvoor zijn heel goede redenen.
De gebruiker heeft zelf de keuze om de software al dan niet te installeren toch?
Dan moet het toch geen probleem zijn om code trusted te maken en te laten functioneren op een webpagina?

Werkend voorbeeld van trusted code:
De media player component welke je kan embedden in je webpagina aan de hand van zijn classid waarmee hij op het systeem is geinstalleerd.

Verder heb ik nog ergens iets gelezen over de mogelijkheid om een NetMeeting component in je webpagina te embedden met behulp van een Netmeeting SDK. Dit heb ik helaas nog niet werkend gekregen.

Er zijn dus wel genoeg (legitieme) mogelijkheden lijkt mij.

[ Voor 1% gewijzigd door Verwijderd op 20-06-2005 16:01 . Reden: typo ]


  • LoBbY_1
  • Registratie: Juli 2002
  • Laatst online: 06-01 11:08
Dit is het zelfde als bijvoorbeeld bij een java-applet. Bij een applet mag je ook niet zomaar socket connections doen, of IO operations. Het heeft idd te maken met veiligheid. Voor het zelfde geld werkt je activeX als (op zn ergst) een trojan.

Een echte golver is nooit uitgeput


Verwijderd

Topicstarter
Java applets hebben op zich die rechten inderdaad niet, maar ik heb gehoord van iets als trusted applets, waarmee je dergelijke dingen wel kan.

Maar inderdaad geldt voor alle web based technieken dat veiligheid een belangrijk punt is, maar de oplossing 'maak dan maar geen web based applicaties' is ook niet echt een uitkomst voor een bedrijf dat web based applicaties ontwikkeld. Verder ligt er nog een grote toekomst (lijkt mij) in web oplossingen.

Maakt het overigens uit of er een DLL in C# wordt gebruikt op een webpagina, of een trusted java applet voor wat betreft veiligheid?

Verwijderd

In principe niet. Ik heb dit ook een keer geprobeerd maar ik kreeg het toen niet aan de gang door security restricties. In de sectie 'Administrative Tools' van je configuratiescherm zit een control applet om de rechten van .NET assemblies te managen. Wat ik heb geprobeerd is om m'n assembly te signen en toen via deze tool alle rechten aan de gesignde assembly toe te kennen, maar mij is het iig niet gelukt. Ik heb de link over die rechten niet bij de hand, maar op MSDN heb je dit zo gevonden.

De tutorial die ik heb gebruikt vind je hier op de codeproject. Misschien heb je daar nog wat aan.

Als het je lukt, laat het ff weten! :)


Ps. Een Java applet heeft trouwens wel default de rechten om een verbinding naar willekeurige poort te openen op de webserver vanaf waar hij geladen is. Misschien hebben ActiveX applets dezelfde restricties?

[ Voor 15% gewijzigd door Verwijderd op 21-06-2005 10:44 ]


  • Janoz
  • Registratie: Oktober 2000
  • Laatst online: 04-05 14:55

Janoz

Moderator Devschuur®

!litemod

Een activeX component is niet de enige manier om een webapplicatie te bouwen. Ik heb sowieso een beetje het idee dat je nogal snel naar onnodig overdreven oplossingen grijpt gezien je shoutbox activeX component en het feit dat je je blijkbaar geen voorstelling kunt maken van goed werkende uitgebreide webapplicaties zonder gebruik te maken van een client side executable als een javaApplet of C# dll.

Natuurlijk is een webcam iets dat niet met standaard componenten op te lossen is (alhoewel flash wel de mogelijkheden heeft, maar je hebt al aangegeven deze niet te willen gebruiken vanwege kosten overwegingen), maar ik begrijp niet waarom je naar een serversocket grijpt. Naast het feit dat dat iets is dat erg security gevoelig ligt (je kunt wel zeggen dat je er alleen legetiem gebruik van maakt, maar daar heeft een gebruiker of een securityManager natuurlijk helemaal niks aan) gaat dat legio problemen in het gebruik geven. Zodra de gebruiker een firewall of router heeft gaat de boel bijvoorbeeld niet meer werken.

Probeer te begrijpen waarom bepaalde dingen niet toegestaan zijn. Het is namelijk echt niet gedaan om ontwikkelaartjes te pesten. Er zijn genoeg legitieme manieren om een socketverbinding op te zetten waar de SecurityManager geen enkel probleem mee heeft.


Om op de laatste vraag nog even terug te komen: In principe is een java applet makkelijker. JVM en Flashplayer zijn imho de enige componenten waarvan je mag verwachten dat je gebruikers deze kunnen installeren. .NET werkt eigenlijk alleen in IE op windows. Als je er geen problemen mee hebt je te beperken tot Windows en IE kun je imho wel verwachten dat je gebruiker het .NET framework geinstalleerd heeft of dit zou kunnen doen.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


Verwijderd

Topicstarter
Voor wat betreft het signen van het component ben ik ook mee bezig geweest, maar hier heb ik niets voor gevonden om dit automatisch te laten plaatsvinden.


Welke overige manieren zijn er dan om een socket verbinding op te zetten waarmee je de securitymanager niet pest?
Er moet toch communicatie plaatsvinden tussen twee clients om bijvoorbeeld audio data over te zenden, dan moet er toch een client een luisterende poort open zetten?
Audio en videodata via een server verzenden lijkt mij nl niet echt een optie...

Verwijderd

Een client hoeft in principe nooit een luisterende poort open te zetten... sorry, dat deel van je probleem had ik even gemist, maar aan een poort luisteren is inderdaad in Java (en ik denk dus zeker ook in C#) niet toegestaan.

De enige reden die ik me hiervoor kan bedenken is als je je applicatie Peer-to-Peer wilt op gaan lossen, wat me zowiezo niet de meest geschikte architectuur lijkt. Waarom luister je niet gewoon op een poort met je server programma op de webserver vanaf waar de webpagina met de ActiveX control wordt geopend? Dan omzeil je waarschijnlijk het grootste deel van de beveiligingsrestricties.

  • Janoz
  • Registratie: Oktober 2000
  • Laatst online: 04-05 14:55

Janoz

Moderator Devschuur®

!litemod

peer 2 peer is in een untrusted omgeving sowieso niet mogelijk. Het is dan namelijk niet meer mogelijk om de sandbox te garanderen. In principe zou het dan bijvoorbeeld mogelijk zijn om een applet een smb share te laten benaderen van een afgeschermd corporate netwerk en dit vervolgens weer naar een kwaadwillend persoon te versturen.

Standaard oplossing in dit soort gevallen is om beide clients een verbinding naar de server op te laten zetten, en de server vervolgens de data door te laten geven.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


Verwijderd

Topicstarter
Voor tekst data is dit wel een oplossing, maar video+audio data leveren veel meer verkeer.

  • Janoz
  • Registratie: Oktober 2000
  • Laatst online: 04-05 14:55

Janoz

Moderator Devschuur®

!litemod

Met peer2peer zul je af moeten zien van een web applicatie. Hiervoor kun je beter een stand allone applicatie bouwen. Daarnaast zul je altijd de 'via de server' optie in moeten bouwen voor bijvoorbeeld de mensen die achter een firewall zitten of die beiden achter een router zitten.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


Verwijderd

Topicstarter
Ik denk dat video+audio via de server laten verlopen vragen is om moeilijkheden. Als er 10 personen aan het videochatten zijn op de server (geen multicasting), laat je de lijnen aardig vollopen lijkt mij.

Overigens er is na overleg vandaag besloten om de applicatie toch als stand alone applicatie te ontwikkelen. Dus mijn dank voor allen voor de informatie! Dit scheelt namelijk een hoop rompslomp bij de ontwikkeling (vind ik persoonlijk).
Pagina: 1